Hacker News new | ask | show | jobs
by lowercased 1466 days ago
> The dark side of this mentality is that it creates the same situations whereby people believe their own intuitions are equal to professional scientific research. If you believe no one knows what they’re doing and all adults are just making it up as they go, why would you listen to experts instead of inserting your own opinions based on your Facebook research or some quip you saw online?

Or folks on your own team?

I've got a colleague with over 20 years of software/web/dev experience, working as a contractor on a poorly run team. Routinely there are questions about "how should we do X?".

My colleague has done much of these X situations for 10+ years, and says "we need to do it like Z. I've done Z for 8 years and this is the normal pattern for this scenario".

There's always regular pushback from others on the team with "well, I read $foo which says Z can't scale!" and similar things. These are typically coming from people with ... 1-2 years experience. One guy just graduated high school last year, but the PM gives everyone's views equal weight because "well, no one can know everything, and everyone's got a right to their opinion!"

Just because the 20 year old doesn't know how to do X, or read that Z is 'slow' does not mean their views are equally as valid as someone who has actually done X multiple times over years, and in some cases has already implemented the X on a project.

He's likely not going to be there much longer - he's already splitting time with other projects, and will ramp down if there's not some bigger changes on that team.

1 comments

This is common, and so is the 1-2 years experience dev churning out a ton of code. It gets work done and builds credibility, but then they make some glaring architectural mistake thats tough to rip out. PM can't see it, and eggs the dev on to keep delivering. Sometimes this is great, sometimes not. Depends on the company and the needs of the tech stack
Further to the point above, the 20 year old in this story does not actually deliver anything. But his protestations about 'slow' and 'legacy' and 'best practices' are like a siren song to some other non-tech folks who keep saying "well, sure, we don't want to be slow - we want to scale - let's do what $person is suggesting". Except... nothing gets done. Months have gone by with no measurable progress, but lots of 'review sessions' identifying $newStackX as the gold standard.

If someone wants to challenge or push back on decisions I make (for example), you better be able to deliver something a) good or b) fast. IDEALLY both, but... if you give me POC code quickly with obvious issues BUT demonstrate some improvement - that's great. We can iterate, if it's quick. Give me some fully fleshed out measurable improvement that takes a bit longer, but has some tests, docs, etc. That's good too.

Sit around and just continually 'back seat dev' on stuff I ship, while literally being incapable of delivering working software of any size, or even supporting your own stuff that you think is 'awesome'... we won't be in agreement on anything.