41–50 of 112 posts
+ a meta-point: Learn these through experience, not in a classroom. Having managed engineers in industry and also gone through a masters program in engineering management, 90% of what makes me a decent manager/leader/coach today can be attributed to the former.
Strongly disagree that an engineering manager shouldn't code; that is the shortest way to lose the respect of the team. Don't get me wrong; you need not be the "best" or the expert in all areas, but you do need to stay on top of technical developments both within and outside your organisation.
Engineering managers that also code a lot usually fall short on the managing part, at least in my experience. Imo it's better if they focus on building a great team, guiding the team in the right direction by doing code reviews and making the hard decisions and be somewhat of a shield between the devs and other internal or external stake holders. Sounds boring, but provides more value as a whole imo. It's also why i…
Earlier quoted context omitted.
Measure timeliness with respect to estimates. Measure the transparency in which they communicate the progress and focus of their work. Measure the clarity in their design and scoping. Measure what other developers say about their work in peer reviews. Measure how well their work runs in production, how many escalations and emergency bug fixes are needed?
> Measure timeliness with respect to estimates What if you have an employee who doesn't know how to do software estimation? Do you know of ways to teach people how to do estimates or resources/habits they can follow to learn how to estimate how long tasks will take? I ask this as someone who has only received the advice "go with your gut and triple it." There is a book by Steve McConnell on estimating larger projects…
Earlier quoted context omitted.
There's an easy way to accomplish this: Commit yourself to 95% reading of code and 5% writing. Through great code reviews, spread your knowledge through the company and make others as good as you. Has the added benefit of making the stack more homogenous. (I still code review 50% of all commits relating to the data model - SQL & API interfaces myself) Then about the 5% - this is high prio, high visibility fixes where…
Code reviews by a dude who codes only a little and has formal power are pure hell. It is tricky when he is wrong, he can force you to do things that cause trouble and so on and so forth - all that because writing and reviewing code are much different and he is gradually out of touch.
How hard is it to answer that question?
Earlier quoted context omitted.
Code reviews by a dude who codes only a little and has formal power are pure hell. It is tricky when he is wrong, he can force you to do things that cause trouble and so on and so forth - all that because writing and reviewing code are much different and he is gradually out of touch.
Why did you code it that way? How hard is it to answer that question?
I just ran into this response yesterday, and I ended up going over his head (unfortunately) and asked our DBAs for a recommendation. DBA solution worked faster than either of the previous two solutions. I still need to apologise for that one.
Having just spent a couple weeks on a pretty hard engineering problem, after having done more "architecture" stuff for quite a while, I would definitely add one thing to the Do's: * Protect your engineers' attention. As a manager you are the primary firewall between the world of distraction and the world of getting shit done. Most places these days have institutionalized some amount of distraction -- the various recu…
> Protect your engineers' attention. Can you elaborate on "attention", and what does "protecting" it look like? (I've seen this reasoning used to keep developers out of requirements gathering, for example.)
What you want to avoid is random people (and that includes higher ups) pinging the engineers directly. That can be incredibly distracting and can result in large decreases in productivity, not to mention higher likelihood of bugs and other problems as the engineer is kicked out of their "zone" and loses their concentration.
http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-...
Having just spent a couple weeks on a pretty hard engineering problem, after having done more "architecture" stuff for quite a while, I would definitely add one thing to the Do's: * Protect your engineers' attention. As a manager you are the primary firewall between the world of distraction and the world of getting shit done. Most places these days have institutionalized some amount of distraction -- the various recu…
> Protect your engineers' attention. Can you elaborate on "attention", and what does "protecting" it look like? (I've seen this reasoning used to keep developers out of requirements gathering, for example.)
My attention is my ability to concentrate on what I need to do right now -- not what the company needs in a broad strategic sense, not what the stock is doing, not what might be on the horizon in a few weeks. All of those things are important to me but my attention can only be on one at a time. And I think the reality of serious software engineering is that sometimes you need to concentrate on the code and not on the other things.
Protecting my attention means knowing when I need to be in the "zone" (asking if you aren't sure); giving me plenty of warning if I'm going to be involved in things like requirements meetings; totally insulating me from any corporate politics except where I've asked to be informed or it directly affects me; and escalating appropriately (HELO phone?) if I'm too busy to answer e-mails/chats.
I absolutely think you want engineers in requirements meetings, but I also think that if you have an engineer who should be in the requirements meeting and she's super busy implementing that autonomous social-graph API then hey, move the meeting.
Earlier quoted context omitted.
There's an easy way to accomplish this: Commit yourself to 95% reading of code and 5% writing. Through great code reviews, spread your knowledge through the company and make others as good as you. Has the added benefit of making the stack more homogenous. (I still code review 50% of all commits relating to the data model - SQL & API interfaces myself) Then about the 5% - this is high prio, high visibility fixes where…
Code reviews by a dude who codes only a little and has formal power are pure hell. It is tricky when he is wrong, he can force you to do things that cause trouble and so on and so forth - all that because writing and reviewing code are much different and he is gradually out of touch.
Earlier quoted context omitted.
There's an easy way to accomplish this: Commit yourself to 95% reading of code and 5% writing. Through great code reviews, spread your knowledge through the company and make others as good as you. Has the added benefit of making the stack more homogenous. (I still code review 50% of all commits relating to the data model - SQL & API interfaces myself) Then about the 5% - this is high prio, high visibility fixes where…
Code reviews by a dude who codes only a little and has formal power are pure hell. It is tricky when he is wrong, he can force you to do things that cause trouble and so on and so forth - all that because writing and reviewing code are much different and he is gradually out of touch.
Earlier quoted context omitted.
There's an easy way to accomplish this: Commit yourself to 95% reading of code and 5% writing. Through great code reviews, spread your knowledge through the company and make others as good as you. Has the added benefit of making the stack more homogenous. (I still code review 50% of all commits relating to the data model - SQL & API interfaces myself) Then about the 5% - this is high prio, high visibility fixes where…
Programming is a skill just like management. I would argue that if you spend 5% writing and 95% reading you won't be maintaining that skill. If you come from a strong technical background when first promoted (Being the go-to expert on the team or similar) then you can probably keep the respect of the team for a while but eventually others will rise to fill the gap (After all there is 95% of a rockstar programmer's ti…
Reading lots of code also gives a broader perspective than writing lots of code, which requires a sort of tunnel vision. Both the deep and the broad perspective are useful on a team.