Ask HN: Slow engineers, did you get faster? How?

After four years, I left my first team in March to join a new team at the same company. Now it's performance review season, so my old manager forwarded some notes to my current manager about my prior work. Basically it said that I had solid results, wrote some really stable code, "championed" testing and testability for the team, and that people liked working with me. I haven't seen it yet, but apparently it was a lengthy essay.

But he also added that the one thing that had been keeping me from moving from SDE I to SDE II was my velocity at turning out deliverables. I'm basically the last one of my peers who hasn't made the jump, and that was the ongoing reason from my old manager. I'm getting passed by newer engineers pretty regularly now, and I've been at my current level for about three years.

In the last couple weeks since my new manager got that letter, she's seemed really concerned about my velocity. It wasn't until this Friday that she had read anything about it. Yet in the same time span, the new-guy-on-a-new-team feeling was pretty much gone, and productivity was up. I got put on a pretty high-visibility, high-impact feature for this month. Before, I think my manager saw me as ready. Now I think she sees me as a liability.

I was starting to get worried that I'd never meet this speed expectation at my old job; but now I'm extra nervous that if I slip on any deadline even a little bit, I'll seal this reputation with my new team and make it my label from here on out. The Slow Guy. Sure he's nice, and he writes maintainable, reliable code... but if we need it done soon, might as well give it to an intern!

Q: Did anyone else shake a reputation for being slow? Is there any hope I can do to put this velocity thing to rest and catch up with my peers? Or am I just a B engineer who peaked right out of college?

PS: I'm getting married next month. Will I have to choose between my marriage and permanent 12 hour days?

Were the deliverables fixed by the management or you were responsible for the estimate? If you are the one who consistently underestimates the time, maybe that's a legitimate point.

Ultimately, it is stupid if they'd favor giving a project to an intern over you despite your results/writing maintainable code etc. The company will pay for shit code accrued over time.

I don't know enough about your situation, but you should know that A) managers are just people and make errors in judgements and B) sometimes managers exaggerate stuff like that to get more from employees (12h days for instance).

For A, you could pull a bunny out of a hat - finish a project early (as early as possible) and make sure it is noticed (but don't brag about it). For B - sometimes you have to compromise, and sometimes you don't have to. Can you find another job? Do you want to? Can you stand up to them? Depends on your situation...

Last but not least, "slow" is not the same as "not meeting the deadlines". Are you meeting them? Make sure this is noticed! I would rather have a "slow" member in my team who can reliably deliver good results in time than some "hotshot" who can delivers tons of (unusable) code in very fast time...

Bottom line: in companies what should matter is how much you contribute. Just make sure others notice it too.

I don't know enough to truly speak on this, but it honestly sounds to me as if you are someone who is very rational and thinks before acting. If this is a detriment to your employer...I don't know what to tell you.

I don't know if I've ever been "slow", but I've definitely gotten faster over the years. My personal measure of how experienced I've become as a developer is the number of problems that I treat as a hash table lookup (vs those I need to actively debug). Given that, there are a few possible causes for your so-called "slowness".

If you spent 4 years on the same team, it's quite possible that rather than getting 4 years' worth of experience, you got one year of experience 4 times over - by not constantly being exposed to new classes of problems, you haven't actually expanded your ability to solve problems by a significant amount.

Another cause is that you may not put enough thought into the type of work you find yourself doing. There's a fabulous talk by Rich Hickey (http://www.infoq.com/presentations/Design-Composition-Perfor...) where he compares software developers to improvisational jazz artists. The gist is that Coltrane didn't just get up on stage and play music that magically popped into his head: he practiced, and tried stuff out, and then on stage he composed little things that he already knew worked into a single performance. Software is much the same way - by playing with new things in your spare time, reading about different patterns and libraries, and thinking about the types of problems you face day-to-day, you're building up a huge library of small solutions that you'll compose into software at work.

Reading HN every day is a good start. I like to use HN as a source of inspiration and a place to discover things to learn about. Were it not for browsing HN pretty much every day, I wouldn't have discovered most of the things to which I attribute to my growth as an engineer over the past few years. Certainly, I wouldn't have grown much if I didn't actually investigate those things, but it's great to have a constant source of new "known unknowns".

The degree to which you can put any of this advice to use, is of course, entirely dependent on how much time you're willing to devote to getting better at building software. Aside from spending time with my fiancée and son, I don't do much other than what I've described above. As a result, I'm fairly one-dimensional, but I'm more interested in writing great software than being interesting at dinner parties, so it's an acceptable tradeoff for me (the other result being that I'm told I'm pretty damn fast at writing good software).

TL;DR practice, read, practice, read, practice.