Earlier quoted context omitted.
> ...or broke it down into smaller achievable tickets that continuously added to their points totals. These teams were filled with happy stress free developers. But that is part of the point of scrum. To break down stories into consistently stress-free achievable stories, rather than big risky ones filled with unknowns. I'm not saying this was a good workplace, it doesn't sound like it at all. But to me, it sounds li…
OP here. You are right, but the minimum point totals eliminates any benefits that can be achieved from scrum, it forces engineers to incentivize survival over project momentum. If a story is really a 3 pointer but I know that if I close 2 3 point stories in a week then I am pipped, suddenly those 3 point stories are 5 point stories. On the teams that played fair, it was a mix of sr. and jr. and the sr. measuring that…
The worst programmer I know
391–400 of 668 posts
Re: The worst programmer I know
#392I worked at a company for a couple years where you had to produce 10 points a week or you got pipped. Didn't matter if you were a jr or sr. I worked on a few teams there and you could immediately tell how the teams measured points by the stress level of the developers. Teams that attempted to measure the points in good faith were stessed and most of them showed signs of burn out. They regularly worked 60 hours a week…
I read this as the teams that attempted to measure in good faith did a poor job at estimating. If management tells you that you are required to deliver 10 points per week, then 10 points should take you 40 hours with rare exception. Whatever other idea you had in your head of what 10 points "should" mean is simply incorrect.
Re: The worst programmer I know
#393Earlier quoted context omitted.
Can you reassure me then with the data that backs up your claim? Because in my very long career I've seen a lot of people use heuristics when deciding who to follow up with. "According to a 2018 CareerBuilder survey, 70% of employers check out applicants’ profiles as part of their screening process, and 54% have rejected applicants because of what they found."
HR are not going to reject an incredibly experienced senior guy with a CV as long as your arm because of the title of a blog post. Your quote doesn't even suggest they would, and I'm not going to cite any evidence because it's honestly just a patently absurd proposition.
I'm basing this on real world experience.
Re: The worst programmer I know
#394Earlier quoted context omitted.
Was Tommy upset?
Absolutely! But after a while he knew why there was no kind of reward whether in the form of a financial compensation, a promotion or even additional days of vacation. Simply because the law of work does not have a section for exceptional performance/achievement.
Re: The worst programmer I know
#395Earlier quoted context omitted.
It sucked being that person back then too. The idea of measuring everything and acting on the numbers you can get is from the 19th century. Managers have been doing that same kind of practice since then, with the same kind of result (it's a very reliable result), without a change.
A lot of that is from Frederick Taylor, who invented “scientific management”. He did experiments where he would have workers shovel piles of ash from one side of a line to the next, giving them a new shovel size each day. Found that the ideal shovel size holds 21 pounds [1]. The ideological assumption of his work is that management exclusively does the thinking and the workers exclusively do the doing. This falls apa…
AKA every time.
AFAIK, Taylor himself wasn't nearly as radical about doing measurements and only acting on them nor about managers deciding everything and not listening to the workers as Taylorism preaches. His work was one of the many, many management theories that was completely modified to appeal to incompetent power-hungry wannabe dictators (and yet blamed on the person proposing the original theory).
Re: The worst programmer I know
#396Earlier quoted context omitted.
Get your resume. HR looks up your name. Throws out the resume. It could be fun if you can get an interview. It might hurt you though.
If HR is going to throw it out because of the title alone, they're going to be obnoxious to deal with even in the scale of HR departments.
Sometimes we need to pay rent and deal with obnoxious HR departments.
Re: The worst programmer I know
#397I worked at a company for a couple years where you had to produce 10 points a week or you got pipped. Didn't matter if you were a jr or sr. I worked on a few teams there and you could immediately tell how the teams measured points by the stress level of the developers. Teams that attempted to measure the points in good faith were stessed and most of them showed signs of burn out. They regularly worked 60 hours a week…
> ...or broke it down into smaller achievable tickets that continuously added to their points totals. These teams were filled with happy stress free developers. But that is part of the point of scrum. To break down stories into consistently stress-free achievable stories, rather than big risky ones filled with unknowns. I'm not saying this was a good workplace, it doesn't sound like it at all. But to me, it sounds li…
Re: The worst programmer I know
#398Earlier quoted context omitted.
Tech Lead is a very difficult role. :/ If you are immature or competitive, you cease being a force multiplier to be a morale destroyer. If you are more of a domain expert than your Product Managers, you will spend your time fighting and refining tasks to build features the right way. If you don't have enough time to code, you'll go obsolete.
I'm the frontend lead in a company of about 200 people (mostly devs) these days, and the idea of being a force multiplier is spot on. I'm not there to be the best dev or the most knowledgable; I'm there to lead the conversation and amplify people who are saying good things. Having a pretty deep understanding of the tech is useful so I can tell what those good things are. I am absolutely not in the company to show off…
The problem is not needing discovery work or understanding the problem. The problem is when the Tech Lead is the one who's providing all the data for that discovery, or helping them understand the problem better, because of lack of expertise of PO/PM. Or having to push back because of incomplete knowledge.
If there is lack of information or incorrect information, POs should be able to get that information themselves. If a TL is the sole source of that info, then it becomes an issue.
IME this is very common. And it takes too much time of a Tech Lead's day.
Re: The worst programmer I know
#399Earlier quoted context omitted.
I'm rarely paired because pair programming just isn't something we do in the company outside of just helping people with their little issues. It's not an encouraged practice. There's nothing deep about it. It sounds like you're trying to insinuate something negative about me.
I assume they are insinuating that you are coming off as arrogant and only interested in teaching. They should definitely just say so, though. In a good pairing environment everyone is learning from everyone. You didn't explicitly say you were looking to learn for others though you also didn't explicitly say you weren't. As far as I'm concerned, in the best pairing environments everyone is always pairing with everyon…
Well that's the thing. The only reason I'm in a senior position at this company is because I never stopped asking questions and I still don't stop asking questions and learning from people more knowledgeable than me. I used to spend hours sitting at one guys desk just asking questions and listening to rants and just gathering knowledge.
I learned that this was the fastest way to progress and get better at the job, but I'm not finding that juniors and other less experienced devs are doing the same thing because they're worried about wasting people's time. And people are less likely to encourage this behaviour because they have high priority work. I got away with it when I joined the company because the rate of change was so much lower and so things generally just took longer.
Re: The worst programmer I know
#400Earlier quoted context omitted.
The saddest thing is that some bosses want throwaway code. I had a short stint once in a company where the owner wanted the web service rewritten from scratch every 6 months so they could use the newest web framework and follow the current fashion. He would hire a 5000 LoC per week hero on the spot.
It depends on “when” along the timeline of the project. If we don’t know if anyone will want the product, the quality of the product is less valuable than validation of product market fit. Later, I care much more about avoiding accidental complexity and having a great technical foundation.