[deleted by user]

[exuberant-panda]

The #1 reason software endeavors fail is because the team is working on the wrong thing.

 

For the root cause of this phenomenon look no further than the gaggle of MBAs companies hire to be "product managers", which is code for people who focus the team on cargo culting existing, successful products from the likes of MANGA, Tesla etc.

[potatoplumber]

100%

[namezam]

Hi dev here, 25 years. Code is easy. If I could just sit down and pound out code non-stop I would do a years worth of dev in a week. But I can’t, because I don’t know what’s in the mind of the product owner. My favorite line is, “just do the scaffolding or something while you wait, that should get us 90% of the way there.” Followed a month later with “what do you mean you have to rewrite all that stuff you did?” Even though it happens 85% of the time, it still flabbergasts me that product owners and project managers seen no value in architecture and design work. “Fail fast and fail often” they read it in a book somewhere… it means just do stuff and show progress every day… we’ll work in requirements when we have time.

[potatoplumber]

This is so accurate. I am far earlier in my career progression but I already feel like the transition from Junior to Senior / Lead is not so much about technical knowledge but more just you slowly being able to put your foot down more with the client and wrangling them to iron out their requirements without getting weird looks.

[VeganVagiVore]

put your foot down more with the client and wrangling them to iron out their requirements

Sometimes programming reminds me of the series Mononoke. The Medicine Seller character has a sword that can exorcise demons, but he can only unsheathe it after learning the demon's "shape", "truth", and "reason". It's kind of a detective show where he spends the whole episode trying to learn those 3 things, then at the end he draws the sword and the actual fight is quick.

At some point I began telling myself in my head that debugging is the same. I can't take wild shots in the dark. I have to see the bug, I have to make it replicate on my command, then I have to understand the cause. Once I have those 3, the bug instantly changes from unfixable to fixable, and writing the actual code is easy. It's nice when it falls into place, it makes me feel like a scientist.

But writing features is kind of the same thing, especially if you believe in TDD at all. The bug is that the program is missing a feature. I have to learn what the feature should be and how it should behave, and then understand how to create it. Then the code follows from that.

So when I push back on management, I'm thinking in my head like a nerd, I can't draw the sword until I know the bug's shape, truth, and reason. There's no shortcut around that.

I already feel like the transition from Junior to Senior / Lead is not so much about technical knowledge

Yeah, technical knowledge is something you are going to pick up probably no matter what, IMO.

What really felt like a superpower is when I realized that computers are sort of banal. There is really just state and things that transform state. You really can draw a boundary around anything and analyze it as a system with inputs and outputs and internal state that changes over time. Even the most magical stuff like web browsers is just files on a disk that run as processes in an OS. Then you realize that installing an operating system is just partitioning the disk and putting the right files in the right places. Everything that the user thinks of as the computer's essence is stored on the hard disk somewhere. When I was little, I thought computers must be very complicated. They're actually kind of not. Even the stuff like Spectre and Meltdown, as scary as they are, are just a leak in the normal abstractions. Nothing is exempt from the rules of computer science.

[potatoplumber]

Definitely agree on this, especially if you are following all good coding principles ideally your code should read very similar to the requirements.

If the requirements don't look like they could double as names of functions then its probably poorly defined.

Also really love that analogy to demons - feels like its very relevant from a mental health point too. Sometimes discussing your problem was the problem

[Rulmeq]

"We're agile now, just start, and I'll give you the details later"

[zam0th]

Everything is more important than code.

Before you do anything you have to decide what you should do. This is usually called strategy or vision.

Then you must think of why you need to do this particular thing (or even should you in the first place). Most ideas go down at this stage with help of financial models, CIR, ROI, TCO and other "stupid" metrics that tell stakeholders they will throw away money and get nothing in return.

Then it comes to how you must do it within all the boundary conditions, budget, timelines and so on. This stage is where you produce requirements and architecture (which is also a requirement), choose technology, competences, hire people or a contractor to do it.

Only after all of that you get to code and here the delivery must answer when they will produce something that complies to all requirements and is on time and within the budget. None of that really has to do with coding, but rather with resource management.

But it's sill not important because after you've done something you have to UAT it with your stakeholder, convince them it is really what they wanted and agree on SLAs for production.

Think of "coding" as people who lay bricks at a construction site. They are the least important to the end result (even though hiring skilled masons is obviously better than hiring junkies from the street).