[ljm]

On that basis I’d consider the junior to actually be more senior, as understanding the need of the user and building that is vital to the role. A senior engineer who churns out code without taking that step to understand the domain and build the right thing is not, in my estimation, senior at all.

Bashing at something until it finally works is, to me, something we do as beginners when we’re still in the mindset of solving every problem with code.

[jshowa3]

You'd be very surprised then at how fast some people at companies bang out code with very little understanding of the problem, get it done fast, and look like heroes because it works. They then build up an expectation of getting things done fast because "time is money" and end up with a garbled mess of spaghetti code that functions.

Most senior developers that I know are so good at the above that very little communication is required about even the problem. So in reality, they end up sacrificing the team and becoming one man armies.

This goes on until retirement, and then a junior replaces them because they're cheaper and they're stuck with trying to learn a huge ball of code on their own, because teams became obsolete and documentation was an after-thought, that could have been done with a bit more effort on the senior developer to get out of their box and actually impart knowledge.

However, there is the opposite end of the spectrum where they write great code and could do everything themselves while still knowing crap about the problem domain. At that point though, does the PD really matter? Most people , including customers, just accept code results on their face anyways.

[scarface74]

You'd be very surprised then at how fast some people at companies bang out code with very little understanding of the problem, get it done fast, and look like heroes because it works. They then build up an expectation of getting things done fast because "time is money" and end up with a garbled mess of spaghetti code that functions.

And honestly, experience tells you when that's okay. If you work for a venture backed company where the owners and founders only goal is to get something up and running to convince investors to give them money or to survive long enough to go public (statistically unlikely) or to get acquired, the goal isn't to make good code that can be maintained long term. They don't care if the whole business is built on a house of cards that will fall as soon as they get acquired.

Too many employees drink the kool-aid and think the owners are interested in anything else except for an exit strategy.

"Great code" rarely gets someone promoted or recognized.

[plutonorm]

In my experience in industry, the developers are seldom if ever allowed access to what the client actually wants. That's what the po or product manager/ba are for. This is the reason I have come to loathe software development.