Archives for category: Personal Development

My current project is a fairly large team, nine developers in all, three of them are women. I have to admit that I was a little taken aback by the casual sexism of some of my male peers. It wasn’t brogrammer type comments, but gender getting brought into discussions about shortcomings of different team members when it’s not a gender issue. When the conversation is “she will need more oversight on this task, and she’s a woman”, that’s as sexist as saying “she will need more oversight because she’s a woman”. We already know she’s a woman, the gender specific pronoun gives it away.

Read the rest of this entry »

Advertisements

One of the things that I try and do to further my personal development is to read at least one new business or technical book every month. About 6 months ago, I read To Sell is Human: The Surprising Truth About moving Others. I didn’t realize it at the time, but this was the most useful book I read in 2013. Basically, the premise of the book is that most people are in the business of sales; or at least persuasion. Your job may not be to get people to sign on the dotted line, but most knowledge worker professions are about convincing people of something. That’s certainly true about project kickoffs and architecture meetings. The whole purpose of that kind of meeting is to come up with a plan, get people invested in the plan and start the project off in a positive direction.

Read the rest of this entry »

One of my personal project that started off as a thought experiment is slowly turning into reality.  One of the ideas was to see what would happen if I turned up all the best practices to 11  and see what happened. The other part of it was that it was an excuse to use some technologies that I wasn’t that familiar with and learn something new. There were a couple of surprises, some of them very pleasant.  Among them was how much starting load and performance testing early impacted the architecture of the project.

Read the rest of this entry »

For some reason lately, Taylorism has been coming up in conversation. Perhaps because the quantified and systematic workflows are considered the opposite of agile processes or just because scientific management has so dominated American management theory in the last century. Either way, like “The Origin of Species”, most people have heard of “The Principles of Scientific Management” and few have actually read it. Taylor, like all of us, was a product of his times.  One of the things you have to continually put aside when reading it is the classism and elitist attitudes that were pervasive at the time.  Once you get past that, you can start to see what Taylor meant about scientific management instead of what everyone “knows” about it.

Read the rest of this entry »

I recently started a new project.  It took a while to get it going, in fact it took 4 project kickoff meetings before we finally got it moving at all. This was for a set of bug fix releases,  not a whole lot of new functionality. In theory, it should have just do the book keeping, introduce the team, schedule stand up times and start the first sprint the next day. So what happened?

Basically, listening happened. I don’t mean listening in the sense of being able to repeat what someone said, parrot back why they thought a a feature was important. I mean active listening in the sense of everyone really communicating and understanding the problem and how the other people were viewing the problem. The reason it took multiple attempts at a kickoff meeting was that we would talk, there would be some research to be done, a week would go by and the cycle would begin again.

Read the rest of this entry »

I had an incident last week where another developer accused me of applying a double standard to contributions on a project. The root cause of the misunderstanding was that he was looking at the unit test that he copied from the other developer, while I was doing a code review of the code he submitted. That got me thinking about code reviews versus unit tests.

Ultimately, it comes down to the quality of the code review and the quality of the unit tests. A lousy code review is waste of time for all parties and is less effective than good unit tests. The reverse is also true, a good code review beats poor unit tests.

Read the rest of this entry »

I just went to a training class, the first formal training class that I’ve gone to in years. Advanced Distributed Systems Design using SOA & DDD

To say my mind was blown is an understatement.  It’s the entire contents for a semester long class in system architecture condensed into a five day span.  It was the equivalent of trying to drink from the fire hose, far to much, far too fast to really take it all in.

Read the rest of this entry »