Leadership
Results are not the point, followup
In response to a previous post explaining the phrase “Results are not the point“, commenter RenRen Gabás says: Both approaches have their own place. It’s easy to see why Toyota/Lean works well with manufacturing and operations. Continuous service and operations needs continual improvements. However, there are times when you...
Read more
An Unfoolish Consistency: Introducing PEP8 to a legacy codebase
Consistency with this style guide is important. Consistency within a project is more important. Consistency within one module or function is most important. The EVE source code, being initially developed before PEP8 existed, was based on Microsoft’s C++ style. Mostly this is manifested in UpperCamelCase function and method names,...
Read more
Results are not the point?
The phrase “results are not the point” often confuses people new to Lean thinking. It confused the shit out of me, not having really understood it even after my first few books. This is a shame, because it’s such a simple thing. On Friday night, Danny got really drunk,...
Read more
The “Year of Code” Director is Your Boss
There was some hubbub a few months ago when it was revealed the Executive Director of the UK’s Year of Code initiative can’t code [link]. Not that technical (domain) competency is a sufficient condition for management and leadership, but I’d certainly call it a necessary condition. (I’ll use the...
Read more
The manager’s responsibility to review code
I believe any technical leader has a responsibility to review all the code that goes into a codebase.* I am certainly not the only person to feel this way (Joe Duffy as MSFT and Aras Pranckevičius as Unity have said the same). Furthermore, I don’t believe the responsibility to...
Read more
What does your Product Owner own?
In a previous post, I came down hard on Agile leaders that don’t program. Now I’ll turn my sights to another part of the Scrum trinity: the Product Owner. I’ll raise some concerns for what I’ve seen it become in videogames, and suggestions for improving how we use the...
Read more
What if Carl Sagan were a hack?
I was watching the first episode of Cosmos, and Neil deGrasse Tyson talked some about how stellar of a scientists Carl Sagan was and what an impact Carl had on Neil personally. Carl’s abilities were important for his advocacy, because a) it lent him credibility, and b) it allowed...
Read more
“What did you learn?”
When something bad happens to someone (firing, demotion, bad review, big failure), it’s natural for managers to ask that person “what did you learn?“* Unfortunately the answer is rarely what a manager wants to hear, and it’s also largely useless.** Asking the question phrases it as the employee’s problem,...
Read more
Agile project management versus agile development
I have a saying I like to use when discussing Scrum: Scrum is an Agile project management methodology, not an Agile development methodology. Scrum delivers tools for managing the project (planning, scheduling), but very little for how to develop (design, program, test) it. To do Agile properly, you really...
Read more
Using code metrics effectively
As the lead of a team and then a director for a project, code metrics were very important to me. I talked about using Sonar for code metrics in my previous post. Using metrics gets to the very core of what I believe about software development: Great teams create...
