91–100 of 112 posts
Sadly, exactly 50% of engineers are below average, so hiring the best all the time is unsustainable. Thinking that you hired the best, however, is sustainable. The art of managing relies on the capability to get work done by all kinds of engineers. The talent is rarely universally allocated. Some very 'bright' ones will never properly finish the work. Some 'slow' engineers may have remarkable attention to details.
Earlier quoted context omitted.
This would be a pretty nerve-wracking position for an employee. Sometimes it takes a long time to hunt down a single-line change to the code to fix a bug.
I believe it's the responsibility of the person hunting down that one-line change to communicate to their team what was involved with tracking that down. Everyone can learn from a single person's deep dive. An engineer shouldn't feel like they're doing something risky for their career by carefully working through a hard problem with unimpressive code results. If the engineer can't convey why it took a week to find th…
Earlier quoted context omitted.
This would be a pretty nerve-wracking position for an employee. Sometimes it takes a long time to hunt down a single-line change to the code to fix a bug.
I believe it's the responsibility of the person hunting down that one-line change to communicate to their team what was involved with tracking that down. Everyone can learn from a single person's deep dive. An engineer shouldn't feel like they're doing something risky for their career by carefully working through a hard problem with unimpressive code results. If the engineer can't convey why it took a week to find th…
On the other hand, if somebody is constantly disappearing for a week+ with a low complexity ticket, gives cagey standup updates, and then submits a PR that looks like it was thrown together in an hour.. That's a red flag that needs attention.
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…
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 recurring "ceremonies" -- but anything beyond that, it's essential that the manager can protect the engineers from being distracted when they're working on hard problems. While I agree with the general point here, I'm not…
Earlier quoted context omitted.
The best way to do it would be to funnel all communication with the engineers through the manager. This includes questions, ideas for new features, feedback from customers, and so on. 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 ot…
There needs to be a balance here. I've worked in larger organizations where communications got funneled through so many managers that any problem, once it was a cross-team or cross-department issue, got lost in a giant game of telephone. A pretty significant issue that could have been solved by a single configuration property change took nearly a month to accomplish just because the problem got lost through a miss in…
The problem is when requests for larger ideas and tasks do not go through your PM/PO (they should be protecting their team from "malicious" requests so they can meet their milestones on time).
For example, someone from product or marketing shouldn't be able to walk up to you randomly and request that you build something for them. (When they do, redirect them to your PM/PO.)
The single most important thing in engineering management is hiring only the best. The best have two key characteristics: strong technical skills primarily in aptitude but also in technical knowledge, and a great ego-less attitude. It's at least as important to test for ego than for technical skills. Most of our "engineering disasters" were related to lowering our bar for hiring. Some "engineering disasters", though,…
OP means you should be raising the bar for hiring at your org.
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…
The amount a developer (not manager) should code varies from domain to domain. In my work, 5% may be on the low side. But I'd argue in most domains, if you're spending more than 20-30% of your time coding, you're overdoing it and creating too much technical debt.
I'm not a manager, but if I were, I'd promote the folks who find (good) reasons not to code than to code. Some problems need software to solve a problem. But writing software should be a last resort.
Of course, if you're writing throwaway code on a code base that won't last more than a year or two, code away. Technical debt is not a big concern.
Earlier quoted context omitted.
> 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…
I hear you. Estimation is a skill just like coding or documenting or management. Some people have a better knack for it than others. But it is an important skill and a part of being a professional engineer. My rule of thumb is that if you cannot estimate your work to some degree of confidence up front then you haven't spent enough due diligence time and the design before writing code. If your task is too complex to e…
But, you can look at a piece of code and go "no that doesn't make sense. Lets try this instead" and both reason about its quality or run tests on it. You can have nuanced discussions of what makes a piece of code more clear or a tutorial code example more easy to interpret.
It seems like no such nuance is available.
I share your opinion that it is unreasonable for me to expect to be paid without giving an estimate, but I hate hate hate lying to people and so I either avoid giving an estimate or I give one and try desperately to convey "this number is a near-random guess." I have on occasion failed to impress upon someone the uselessness of an estimate of mine and the deception makes me sick.
So I don't know what to do. I have occasionally considered giving up programming, but that seems drastic. I'm currently in a company that doesn't do estimates that much or put too much stock in them and has quite good habits for clarifying scope. But, I feel really unprofessional that I can't estimate.
The single most important thing in engineering management is hiring only the best. The best have two key characteristics: strong technical skills primarily in aptitude but also in technical knowledge, and a great ego-less attitude. It's at least as important to test for ego than for technical skills. Most of our "engineering disasters" were related to lowering our bar for hiring. Some "engineering disasters", though,…
I disagree. Most problems don't require the best, and hiring the best to do things that might be a little bit simple for them is a great way to promote frustration and turnover.
Every organization I've worked for has wanted to and said they hire the best. They didn't actually hire the best, and that's a good thing, because the work we had simply didn't require that horesepower. We needed very good, so I'd hire very good, and it's generally worked quite well.
> It's at least as important to test for ego than for technical skills.
I agree with this. I won't hire assholes. I've inherited a couple when rotating and taking over new teams, and not once has their productivity, subject matter knowledge or any other technical contribution resulted in a net positive when factoring in the attitude issues and other soft impacts to the team. Don't get me wrong, confidence is a quality I like, but to draw from my username, there's a fine line between stupid and clever.
> so if you're a first-time product leader, get an experienced mentor
This is good advice to any manager at any level. The day you're promoted, you're new all over again, make sure someone experienced is teaching you the ropes. And when you're that experienced person, make sure you're teaching someone junior the ropes. This is why I resent climbers/gunners in the organization - they ignore the latter part.
The single most important thing in engineering management is hiring only the best. The best have two key characteristics: strong technical skills primarily in aptitude but also in technical knowledge, and a great ego-less attitude. It's at least as important to test for ego than for technical skills. Most of our "engineering disasters" were related to lowering our bar for hiring. Some "engineering disasters", though,…
The replies are all playing word police and missing the point. Hyperboles are great for getting a point across, except when they're taken too literally. OP means you should be raising the bar for hiring at your org.
So what's the bar? How often, in feedback meetings is the criticism technical versus non-technical?
I know I never get specific technical evaluations from managers. Ever. No exaggeration.