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.
Archives for category: Personal Development
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.
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.
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.
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.
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.
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.
Engineering Long-Lasting Software: An Agile Approach Using SaaS and Cloud Computing, Alpha Edition
It’s an interesting primer on Ruby on Rails, test driven development and agile development. It’s geared at undergrad computer science students and does a good job for that.
However, as an experienced professional, I was looking for many of the chapters that aren’t written yet. For example, the chapters on creating testable javascript and writing maintainable client side code were missing. In a nutshell, wait for the beta edition if you already know rails.
I thought that it was an interesting experiment in lean writing. The idea was to write just the chapters that you need now and see what the interest is in the other chapters. It will be fun to see what happens in future versions of the book.
I’ve been reading Wait: The Art and Science of Delay it’s been giving me some food for thought about the strange world of software development. Basically, the thesis of the book is that there is a correct amount of delay between the action and the response to the action. The time scale is kind of irrelevant, whether it’s the milliseconds between someone serving a tennis ball and returning the serve, or the days between making a mistake and apologizing.
The martial arts school that my wife and I, Academia Duellatoria, go to just did a weekend of demos and free lessons at the Faire in the Grove. At the time, I was thinking that it wasn’t as successful as I would have liked it to be. Until I thought about it some more later.
Scott's Thoughts 