4 ms·

I get your frustration, but I've also seen some pretty bad code where junior developers were given too much freedom to do the "fun, interesting" work. When con

I get your frustration, but I've also seen some pretty bad code where junior developers were given too much freedom to do the "fun, interesting" work. When concerns were raised during pull request reviews, the inevitable answer was "not gonna change it -- approve it now because my sprint is in danger".

Swizec 11y ago
Of course, but my architect is an ex Java guy with 20 years of experience, 2 years frontend. And I'm a guy with 15 years experience, 10 years frontend. Hence much frustration often.
jsprogrammer 11y ago
Sounds like a problem with management. Decisions shouldn't be made around arbitrary ideas like 'sprints'.
madeofpalk 11y ago
That's a problem with everything. If an obviously junior developer is given an obviously 'fun, interesting' task, they should pair with a developer or have frequent reviews so any problems are caught before pull request stage. You need to catch these sorts of things before you get so late in the stage. Additionally, you need a structure and culture that is able to hold back pull requests if the code is bad - that's the whole point of code review!
hibikir 11y ago
You just hand them fun, interesting work that doesn't do too much damage to the company when it fails. In practice, this means that your most senior people end up doing work that is very interesting, yet very arcane. I mean, anyone senior around here should know that it's precisely making something production ready, as opposed to just 'work in theory', is one of the hardest parts of software: Who hasn't seen some code that mostly works, but is operationally unusable? Something that works with 1 server, but when you put it in 20, it all blows up? It's not about the nice presentation, or the talk where you explain how you turned MongoDB into a queue, but about making a system that works almost all the time, but when it doesn't, it is not the end of the world, and easily fixable. The sad part is, the world is so full of powerpoint architects and projects that don't provide any real value that many people have never seen a system work right. And that's why we see tons of SV companies that are built around tire fires: Nobody in charge of anything has ever seen a system that we shouldn't be embarrassed of.
- erichocean 11y ago
  > but about making a system that works almost all the time, but when it doesn't, it is not the end of the world, and easily fixable This is exactly where senior architects make all their money.
maxxxxx 11y ago
There is a serious project management problem if the excuse "Sprint is in danger" is acceptable. Its quite common though.

Swizec 11y ago

Of course, but my architect is an ex Java guy with 20 years of experience, 2 years frontend. And I'm a guy with 15 years experience, 10 years frontend. Hence much frustration often.

jsprogrammer 11y ago

Sounds like a problem with management. Decisions shouldn't be made around arbitrary ideas like 'sprints'.

madeofpalk 11y ago

That's a problem with everything. If an obviously junior developer is given an obviously 'fun, interesting' task, they should pair with a developer or have frequent reviews so any problems are caught before pull request stage. You need to catch these sorts of things before you get so late in the stage. Additionally, you need a structure and culture that is able to hold back pull requests if the code is bad - that's the whole point of code review!

hibikir 11y ago

You just hand them fun, interesting work that doesn't do too much damage to the company when it fails. In practice, this means that your most senior people end up doing work that is very interesting, yet very arcane. I mean, anyone senior around here should know that it's precisely making something production ready, as opposed to just 'work in theory', is one of the hardest parts of software: Who hasn't seen some code that mostly works, but is operationally unusable? Something that works with 1 server, but when you put it in 20, it all blows up? It's not about the nice presentation, or the talk where you explain how you turned MongoDB into a queue, but about making a system that works almost all the time, but when it doesn't, it is not the end of the world, and easily fixable. The sad part is, the world is so full of powerpoint architects and projects that don't provide any real value that many people have never seen a system work right. And that's why we see tons of SV companies that are built around tire fires: Nobody in charge of anything has ever seen a system that we shouldn't be embarrassed of.

erichocean 11y ago
> but about making a system that works almost all the time, but when it doesn't, it is not the end of the world, and easily fixable This is exactly where senior architects make all their money.

maxxxxx 11y ago

There is a serious project management problem if the excuse "Sprint is in danger" is acceptable. Its quite common though.