The Worst Programmer I Know (2023)
31–40 of 385 posts
Re: The Worst Programmer I Know (2023)
#32Was Tim hired as a teacher or trainer? What I find strange is that it sounds like Tim was not doing any individual work. As a very experienced programmer, I'm sure that I could increase the productivity of other programmers by pairing with them all day. However, is that actually the best and most productive use of my time? In my estimation, I think that overall team productivity would be maximized if I spent approxim…
> Was Tim hired as a teacher or trainer? Do you think that's any relevant? Software development engineers in general are hired to work on projects as part of small teams, and their goal is to deliver projects. It's not story points, it's not burn down charts, it's not PRs, it's not LoCs touched. It's how many projects are delivered, and keep everything and everyone problem free. This means that if you are struggling,…
I don't dispute that; hence the 20-30% pairing. But if it's the case that all day, every day there's at least one person on the team who is blocked, then you don't need a "Tim", what you really need is a new team, because that's an unacceptable level of blockage.
Re: The Worst Programmer I Know (2023)
#33Sounds like Tim was the manager. What exactly was the paid for manager doing?
Instead he would spend his day pairing with different teammates. With less experienced developers he would patiently let them drive whilst nudging them towards a solution. That's not a management activity - that's the kind of coaching you would expect from a senior IC ("Individual Contributor" - I still hate that term.) Generally I would expect a "manager" to have authority over other people in the company: run perfo…
Re: The Worst Programmer I Know (2023)
#34Was Tim hired as a teacher or trainer? What I find strange is that it sounds like Tim was not doing any individual work. As a very experienced programmer, I'm sure that I could increase the productivity of other programmers by pairing with them all day. However, is that actually the best and most productive use of my time? In my estimation, I think that overall team productivity would be maximized if I spent approxim…
I enjoy teaching so that was a much more enjoyable way for me to spend my day, than drinking caffeine and cranking code the rest of the team couldn't understand. I joined that team because they were constantly missing deadlines. When I left that team they were finally ahead of schedule, but much more importantly they had a code base they all understood. That wouldn't have been true if I'd just written all the code myself. I like to tell myself I could have gotten the team ahead of schedule as a solo endeavor writing 80% of the code myself. But true or not, when I left I would have no confidence the team could continue without me.
Could I have spent more time writing code? Probably, but what delivered the most businesses value? I was hired as a glorified software engineer but instead of delivering code, I delivered a team that could produce code. Their manager was *never* gonna do that. So should I have prioritized doing what my job title said? Or doing what's in the best interests of the long term mission? Every situation is gonna be different, if teaching is soul crushing for you, or more importantly, the team refuses to be taught, I would suggest just deliver code. In this case, everyone wanted to learn, so that was the easiest path forward.
Re: The Worst Programmer I Know (2023)
#35Used to be bitten by stuff like this until I figured out something Tim and this author apparently didn’t - the problem is trivially fixed by management by attaching tim’s name to any tickets he may have helped out on. he can ask his teammates to do this and they gladly will, or, nice teammates will usually throw a “figured this out with the help of @Tim” in the ticket. goes a long way to keep “tim” on your team again…
You're absolutely right, but some people just refuse to play silly games. It's odd that the manager isn't ever in the room with the team and doesn't understand his team's dynamics. Giving the benefit of the doubt, he must have been new, but any manager worth his salt will ask people on their team what the team dynamics are.
Re: The Worst Programmer I Know (2023)
#36Re: The Worst Programmer I Know (2023)
#37Re: The Worst Programmer I Know (2023)
#38Used to be bitten by stuff like this until I figured out something Tim and this author apparently didn’t - the problem is trivially fixed by management by attaching tim’s name to any tickets he may have helped out on. he can ask his teammates to do this and they gladly will, or, nice teammates will usually throw a “figured this out with the help of @Tim” in the ticket. goes a long way to keep “tim” on your team again…
Re: The Worst Programmer I Know (2023)
#39Re: The Worst Programmer I Know (2023)
#40Used to be bitten by stuff like this until I figured out something Tim and this author apparently didn’t - the problem is trivially fixed by management by attaching tim’s name to any tickets he may have helped out on. he can ask his teammates to do this and they gladly will, or, nice teammates will usually throw a “figured this out with the help of @Tim” in the ticket. goes a long way to keep “tim” on your team again…
> the problem is trivially fixed by management by attaching tim’s name to any tickets he may have helped out on. I don't think this comes even close to solving the problem. This in fact makes the problem worse, because a) you admit the metric is shit and does not reflect work, b) you opt to keep the bullshit metric but instead try to manipulate it to bump the score under some scenario. That's not desirable outcome by…
I like that approach. Now you can not only have peer recommendations, but also tangible records.