Readit NewsDead Comment
The Agile style user stories that often lack technical details because the author doesn't know enough about the technical details means the developer is the one actually writing the requirements (usually as they are doing the work).
Point 4 - incompetent people. They are great. When they fuck up, which they do often, you can save the day by simply being average. Just make sure people know that you saved it.
Point 5 - meetings are great if remote. You can sit there muted on a zoom call for hours tweaking with your bike or playing games on your other computer.
Point 6 - estimates are always wrong so don't put too much effort into it. What people value is how long you spend making up lies so spend some time on it!
Point 8 - Uncertainty. Let other people handle that and hang themselves with it. That's what software architects are for. Be there to clean up the mess afterwards or at least complain about it.
Point 9 - Eventually you do become able to disconnect from your job. One day the fucks just run out. Embrace that early on and save yourself a lot of stress.
Point 10 - The only soft skill is politics. Any sufficiently large organisation employs many politicians. The best way to deal with politicians is analyse the factions and stay neutral. No one can drag you to their side then.
There is a missing point though: objective one is getting paid. Anything else is secondary. If they stopped paying you how much of a shit would you give about all the other concerns? There you go now you understand. Nothing matters so don't get too wrapped up in it or upset about it.
This seems a little inconsistent to me.
Is it really their fault if the industry says they are qualified and gives them a job when they are incompetent?
Maybe there should be a group of researchers that submit papers that seem believable with known issues to avoid scientific journals stagnating. Maybe the names and institutions of the group submitting papers should be hidden so that more reputable/famous people and institutions get the same level of scrutiny as everyone else.
You'd be better off pair programming everything and forgoing code reviews.
Sometimes I think the people that come up with this shit are sociopaths.
It's possible he is right, but it is also possible that these traits aren't trainable, and without that, you may not have a population sufficient enough to sustain his ideal.
On the engineering side, ideally this is how things are done anyway.
I've never had a problem digging into the ideas presented by engineers more senior than me, and I've always encouraged junior engineers to question any ideas I present.
Everyone, independent of seniority, is blind to giant gaping flaws in their own ideas. People also don't know what they don't know. If I have a gap in my knowledge, any plans I come up with are not going to take what I don't know into consideration if I don't know that I don't know something.
- being presented under-cooked ideas so you do the thinking for them.
- too many ideas (which can lead to the first) with an inability to focus
There is a feedback loop for the first where people don't dive too deeply into their idea because they know they'll get a lot of criticism.
The second can be bad because the idea or its implementation is never polished.
Loading parent story...
Loading comment...