Wednesday, January 8, 2014

Chicago Code Camp 2014 is coming on April 26!

Chicago Code Camp 2014 is coming again on April 26 at College of Lake County. This is the 6th CCC. Find all the details on the website:

I've found this to be a magical event in the past - 200 developers enjoying an all day, free event, on Saturday (usually no work conflict), with 30 diverse sessions from volunteer speakers... Makes you love our profession!

Tuesday, September 3, 2013

Presenting at SDC on Empowering a Team as an Individual Contributor

I had the opportunity to present at the SDC on "Empowering a Team as an Individual Contributor" (9/1/2013).

Most developers are individual contributors (IC) – in other words they do not have direct reports. But even as a non-manager, you can empower an entire team. This is due to the nature of software engineering, where developers create their own tools, a star developer can be 10x as productive as an average developer, and a single developer can use technology for team-wide impact. With the right mindset ("add business value"), and using a combination of hard skills (automation, tooling, code generation, open source, code reuse, etc…) and soft skills (interviewing, mentoring, communication and knowledge sharing, etc…), you can be that IC developer who helps lift your entire team, and have fun along the way.

Monday, February 11, 2013

The one ratio to rule them all

I was reading from "Good to Great", excellent book, and it mentioned one of the things successful companies did was chase a simple, single ratio. Sure, there's always more to it, but that one ratio helps focus the team. For most software departments, that ratio is something like:
(Requested Features / Incident Count ) per developer per month.
Basically, you want to crank out lots of features and have very low incidents. "Emergency" deploys, production bugs, outages – those essentially count as incidents.
All the good things either help increase requested features, or decrease incidents, and hence drive this ratio up.
Increase: Requested Features
Decrease: Incident Count
·         Application frameworks
·         Reusable blocks
·         Code generation
·         High quality, motivated, developers
·         Tools
·         etc…
·         Automated build and deployment
·         High unit testability
·         Low QA bug count
·         DevOps, application monitoring
·         Developer conscience
·         etc…

Most of the time, a team gets into trouble when it starts chasing things other than this ratio:
·         Hours on a timesheet (instead of actually producing something)
·         Face time in meetings or the office (instead of actually producing something)
·         Thinking how their manager thinks (which may not actually increase feature output)
·         High Lines-of-Code count (more codes != more features)
·         "Feeling" busy (merely feeling busy doesn't mean cranking out useful code)
·         Cool technology for the sake of cool technology  
·         Job security via undocumented process
·         Coding to show how smart you are (as opposed to code to make the requested feature)
·         Rating/grading the quality of developers (as opposed to making the business happy with working features)
·         Avoiding mistakes (as opposed to the addition of value)
Sure, these things by themselves aren't bad (avoiding mistakes and using new technology), but they are secondary to the real goal. As long as a developer – or worse, an entire team –  chases them instead of the real goal, they will always be less than great.

Friday, November 30, 2012

Lesson from the flaming BBQ - people who just get it

I was hosting a BBQ over the summer, giving me a chance to use my very rusty "grill master" skills. Stepping away from the grill for just a few moments, I looked back to see huge flames spilling out of the grill. Luckily for me, one of the guys nearby just stepped in and quickly turned down the heat. He didn't track me down and notify me of the flames, ask me if it was okay, or delay in any way – he just did it. By the time I got back to the grill and all was calm, he casually mentioned turning down the heat. He had done many BBQs before, and he just "got it".
That's what a good team wants from its developers – people who just get it. They see a fire, and deal with it. Sure they keep management informed, but they don't make management a bottleneck with and endless stream of questions. These are developers who write that extra null-check, create the defensive code that defaults to a safe value if a param is missing, make a safe business assumption for a validation rule, upload a tool or patch to a shared drive so the next guy can easily get it, you get the idea… In each case, they could do it the "wrong" way, but they risk that and do it anyway.
I think this ultimately stems from management. First, management needs an atmosphere that encourages common-sense risk. Micro-management creates an aura where developers are scared to do the slightest action without multiple levels of approval for fear that no matter how obvious it may seem, it was the wrong thing. If you see the hamburgers burning, but you're not "allowed" to touch the grill, you'll just sit and watch dinner burn, and no one wins. Second, management needs to delegate and encourage and build up developers to take such "risks".  Start small. It's much like a parent training their kids. Sure eventually someone guesses wrong (say they pick the wrong default validation rule and hence need to re-code it), but if they got the previous nine right, then your team comes out ahead. It sure beats eating charcoaled burgers because the team has been trained to only allow managers to turn down the grill.

Thursday, September 27, 2012

Does an expert follow all the rules?

Some people think an expert is one who can follow all the rules. Others think that an expert is one who knows when to break the rules, and can do so to get the job done.
Ideally you'd have both, but I favor the second. The first depends on what the rules are – are they good guidelines or are they ivory tower red-tape and bad process.

Monday, August 20, 2012

Digging with spoons – the case against progress

Say you need to dig a big hole. Do you dig with a spoon or a shovel? Most progress-oriented developers would think “of course we use shovels”, but they continually get surprised when on their real projects the team still essentially digs with spoons. Why? How could someone possibly want to dig with a little spoon instead of a big shovel? Sure, I favor shovels, but I’ve seen over the years that people think very differently, and some people could offer lots of reasons to use spoons instead:
1.       We already have a spoon right now.
2.       It won't really take that long to dig with spoons.
3.       I used a spoon before; you should use a spoon to.
4.       Using a spoon teaches you how to dig, when I was in school they taught us to dig with spoons.
5.       Using a shovel is the lazy way out.
6.       A spoon gives you the granularity you need, you don't really know what you're digging if you have a shovel.
7.       The boss thinks spoons are better (that's how he did it back when he dug).
8.       If we switch to shovels now, that would be admitting we were wrong before.
9.       We need objective measurements (committees, score cards, analysis docs) to truly show if a shovel is better than a spoon.
10.   You’re just advocating using shovels because you read some blog about it.
11.   That big shovel is too heavy; spoons are lighter so we can dig faster.
12.   The shovel wasn’t built here.
13.   You’re not part of the process improvement team, so don’t worry about it.
14.   We’re already successful, so we don’t need to change how we do things.
15.   Well, I actually read that shovels are bad.
16.   Spoons were working fine before you got here.
17.   My last company used shovels, and they went out of business.
18.   Your attempt to change our process means that you’re not being a team player.
19.   Your job is to dig, focus on that.
20.   We can use spoons for now, and then use shovels later.
21.   Not everyone knows how to use shovels, and we can't afford the training costs right now.
22.   We’re under contract to use spoons.
23.   The boss’s boss is friends with a spoon manufacturer; we really ought to keep using spoons.
24.   Are you so special; is a spoon not good enough for you?
25.   If we use spoons, there won't be enough work to do and people will lose jobs.
26.   Our competitors use spoons (I heard), so we should be fine.
27.   Our competitors use shovels, so doing something different gives us a competitive advantage.
28.   This discussion of spoons vs. shovels is just a distraction from the real goal of digging.

Each of these brings to mind some analogy with some past software project where the “slow” way (i.e. spoons) was preferred. Part of empowering a team is to overcome this sort of thinking to show that it’s really in the team’s best interest to use shovels.

Thursday, May 31, 2012

How is a senior developer different from a junior developer?

There is not one right answer. It’s easy to say “a senior dev knows more and does more”, but I think there’s an additional dimension – a junior dev is merely expected to code to the spec, whereas a senior dev fundamentally takes responsibility and ownership for improving everything they encounter.
Here’s a braindump; obviously my opinion. Not a complete list, and not a one-size fits all. I was light on the exact technical requirements (as that changes), and focused more on the concepts. Perhaps in another blog post I’ll do a braindump of what a senior dev is not  (i.e. how is a senior dev different than a tech lead or architect). I’m using C# and .Net as an example, but you could easily substitute those.
There’s also an interesting matrix here.
Writes good code that just works
·         Be able to code to specification is assumed. Should be able to leverage experience and past domain knowledge to fill in some gaps in a spec. Does not need everything explained in complete detail.
·         Writes working code that handles non-happy path and has low bug count. Can quickly create code – does not need to continually refer to reference documentation.
·         Codes for non-functional requirements, like performance, maintenance, testability, security, etc…
·         Can write code with the minimal length and complexity.
·         Thoroughly unit tests applicable code.
Respected by peers
·         Has written a module or tool directly used by others on the team. A senior dev does not just write code in their corner.
·         Can review other’s code and suggest improvements that others will actually implement.
·         Other developers ask for your technical opinion
·         Has built end-to-end products, through all tiers, that ran in production for multiple  releases
·         Has written 10,000+ lines of C# code that passed code review
·         Has created at least 4 different Visual Studio project types (WinForm, web, WinService, Console, etc…)
·         Has created developer tools and utilities besides just visual studio. I.e. has used a profiler or visual studio plug-in or code analyzer or code generator.
·         Has troubleshot a production security or performance error.
·         Has written multi-threaded backend code
·         Has at least 1 technical niche of expertise
Takes Responsibility
·         Does actions to make other developers better, such as writes reusable code, mentors, solves critical path problems, automates a previously manual task, etc...
·         No longer just focused on development, but helps improve the process of development.
·         Can refactor legacy code without a formal project
·         Can resolve unanticipated coding or validation problems without pulling in a more senior resource
·         Can pick up new technologies without formal training (may need formal training for an entirely new platform)
·         Continually looks for code reuse and ways to decrease technical debt.
·         Can tell management what the developer needs in order to be more productive
Has platform-specific knowledge
·         This is the standard list you’d see on a job description (“Knows threading, diagnostics, reflection, IO, etc…, Can explain 5 design patterns, etc…)