Earlier quoted context omitted.
Yes, that is what was written. Would you like to say something about it?
[flagged]
Just say whatever point it is you are trying to make instead of making people guess
The worst programmer I know
251–260 of 668 posts
Re: The worst programmer I know
#252Tim’s productivity score was zero I also have a Tim in my team but he is a net negative. Most of the time he would try to pair up. He just make noises that implies he is following your work. But you can see that is not the case when he tries to make a comment or a suggestion, he is clueless. Trying explaining things to him is a waste of time. Rarely he decides to work on a task himself. No matter how trivial the task…
Unfortunately, I have seen many of these types of people pass by management. The worst ones are the ones who do play political games correctly because they’re the ones who either get away with it at the very least or worse, make the talented engineers want to leave. Basically, the latter can completely destroy good teams.
Yup, I’ve seen many people like this in engineering. They “put all their skill points” into Charisma. Then they go on to build long, prosperous careers by bullshitting and charming senior management, until they themselves are promoted to senior management. It is a reliable, proven career progression for the incompetent.
Re: The worst programmer I know
#253Earlier quoted context omitted.
Having been in the industry since the around 1990, I can tell you that in the first half of my career we had no code reviews, no scrum, no story points, no unit tests. How on earth, you might wonder, did we ship software that worked? I then saw all these things come down the pike one after another during the last half of my career. Clearly to me every one of these benefit management who found themselves apparently un…
Scrum and story points I agree with, but unit tests? You'll have to pry those out of my cold, dead hands!
That's fine. Myself I have little use for them, I prefer functional testing. (Also, before unit tests we leaned on parameter checking in the live code — a kind of always-on unit test I guess).
Management though use the "percent coverage by unit tests" as some sort of safe/buggy software metric.
Management at one team I worked on was pushing for minimal 95% coverage with unit tests. I thought it was odd that they were so singularly focused on this issue. The impression I had was a that they felt that if you have full code coverage with unit tests, and the test pass — you can lay off the QA team because you are assured that you are shipping perfect software.
Re: The worst programmer I know
#254[flagged]
Re: The worst programmer I know
#255When I've been asked to coach someone on "technical leadership" I always ask them to be on the lookout for "facilitator" employees, those whose help makes another employee more productive or effective. I am convinced there are "service oriented" personalities where people get more job satisfaction out of helping someone else do a great job than getting all of the credit for doing something amazing. As the author points out they often "score poorly" and yet losing them will create net decrease in team productivity. I always try to give folks the tools to help distinguish between people who aren't productive because they aren't, and people whose productivity is exhibited in the success of others.
It is never good to measure the "one" metric and manage to that, it results in people who game the metric "winning" and fosters the promotion of such behavior. I pointed this out to Google leadership and to quote Lazlo, "This is the system we have, it isn't perfect but we're going with it, either work within it or don't, it is up to you." :-). That meeting told me everything I needed to know about whether senior leadership was trying to have a better engineering environment or not.
To many new managers come into the job (especially if they were engineers individual contributors before) with the idea that if they keep the "best" members, and move out the "bad" members both team morale will be great and so will the teams output. But they miss that their understanding of "best" is not based on managing people, its based on getting their original job done. As a result they favor people who mirror their skills and habits and disfavor those who have different skills and habits. Getting them to see this and having their eyes go wide with realization is always interesting.
Re: The worst programmer I know
#256I wish I could pair program more. I have so much knowledge to give other members of my team. Domain knowledge, programming knowledge, common pitfalls, etc. You get a code review pass at the time of writing the code, and it means you have more opportunity to change things for the better. Once it's written there's not much appetite for drastically changing working code during code review unless there's a really good re…
this post is really strange because it actually describes a good environment
- code isn’t changing in code review except for really good reasons
- people who need help are reaching out
- projects that need help get additional help brought in
what else are you looking for? this example is about as pair programming as it gets at most places. they’re called silos when people don’t like them and layers of abstraction otherwise but they’re the same thing: no team will have 100% shared info on all parts and knowledge transfers on exits are a decent step to bridge this
if you want to teach the team more, teach them more. usually the best way to do this is in code review. it’s direct comments on code. write a good review you want more people to see? post it in the chat. set up additional time to share ideas with the team. all of these things you can do as an IC while producing code
sorry but this post comes off as “i’m smarter than everyone.” i’m guessing the reason management hasn’t gotten your message is the message isn’t clear. what exactly do you want to do? and what do you need their help for?
Re: The worst programmer I know
#257It sucks being that person today because everything is about optics and that person will get purged. I know from experience. Team players, mentors, software architects; they tend to be tossed aside to make room for coders who can churn out large amounts of code, even as the company's capacity to deliver and maintain features declines over time due to tech debt. Managers always love a developer who can consistently wr…
[flagged]
Re: The worst programmer I know
#258Earlier quoted context omitted.
Frankly it sounds like you need to make this happen. I don't know your company culture but at places I've worked Staff+ engineers aren't meant to wait around for permission to be catalysts and mentor other engineers.
I'm usually the catalyst for change, but that's usually around tech and process. It's more effort for me to try and change my managers mind on what our development culture should be. The company I work for has a reputation for being a bit of a grinder and I've managed to help reduce that reputation in my team gradually at least. But at the moment I have work to do and deadlines to meet, so it's a hard sell to suggest…
Optimizing team efficiency is a team effort. It is a false dichotomy that you either work on “important project with deadline” or do mentoring. There are deeper structural problems that you need to solve first imo.
Re: The worst programmer I know
#259It sucks being that person today because everything is about optics and that person will get purged. I know from experience. Team players, mentors, software architects; they tend to be tossed aside to make room for coders who can churn out large amounts of code, even as the company's capacity to deliver and maintain features declines over time due to tech debt. Managers always love a developer who can consistently wr…
I'm working through this exact situation right now, I really appreciate this insight!
Re: The worst programmer I know
#260> Tim wasn’t delivering software; Tim was delivering a team that was delivering software. The entire team became more effective, more productive, more aligned, more idiomatic, more fun, because Tim was in the team.
This was the money quote.
Teams do big stuff.
Good teams do good big stuff (very good).
Bad teams do bad big stuff (very, very bad).
It seems that the hyper-competitive nature of today's workplace means that engineers consider their own teammates to be "competition," and we never really get a good team. This is especially true, with the mayfly tenures of most engineers, these days.
I'm fairly happy with the fact that I was able to keep a stable team of experienced, high-performing, senior C++ image pipeline engineers together, for decades.
Other managers would bust my chops for being a "Santa Claus" manager, because I refused to burn them out, and often intervened, when other managers were being too hard on them.
It seemed to work. When my team was finally rolled up, in 2017, the engineer with the least tenure had a decade.