Making sure that everyone understands how to use your part (and that the overall architecture is at least coherent), in a big project, is actually more important than if that part is of high quality. And since communication is more important it's the seniors responsibility.
Sometimes I really want to go back to the junior years it was in general more fun back then. But getting to decide the architecture does have its charms.
Personally, I think most software systems could accept fewer moving parts if we allowed certain tradeoffs, and the benefit would be much more empowered engineers.
As a senior dev preventing business from bad decisions and preventing code that should never be written is more valuable.
Code is liability.
To propose solutions I still need to know the code for the system so it is not like suddenly I lost ability to write or understand code. But coding - is only one of many tools for creating a system.
In the end, knowledge of the business details (including their technical implementation) are something that cannot be easily replaced.
Except, this could be done better and cheaper by a literal rock with letters spelling "NO" written on it with a sharpie.
If a software company doesn't write any code, what exactly is it doing? And speaking of bad decisions, surely some have been made already, since everyone is doing the job they're the least qualified for.
Not all companies are “software companies” and it still takes level of maturity to know when to write code and when to outsource.
At the interview for my n-2 job, I was interviewing with the director of IT and a junior to mid level dev.
The mid level dev asked me how I would write an address validation module.
My answer was that I wouldn’t and went into details all of the complications of validating addresses and that I would use 3rd party CASS software. I went on to explain that from what I know about the core business it wouldn’t be a competitive advantage and that “it wouldn’t make the beer taste better”.
The software dev wasn’t impressed, the director was.
I was hired as a senior dev and I was ruthless about using third party software from reputable companies instead of writing code internally. This company has no desire to hire a bunch of devs.
We had specialized consultants for Salesforce, Workday, our data capture system, learning management systems, AWS and everything else.
In about a year and a half, I put myself out of a job, they went public and are running smoothly seven years later from what I can tell talking to former coworkers.
But I sure did have a great story to tell interviewing for my current position working in the consulting department at BigTech.
It made no sense for a health care company that sent at home nurses to special needs kids to write their own in house EMS/EHS system. And they had an in house one that they had been depending on in 2015. It was built using PowerBuilder from 1999 and running SQL Server 2000. They were “locked into” supporting an old PowerBuilder app.
It also wouldn’t have made sense to hire a bunch of mobile developers to write a data capture system written for Android devices for their nurses. I had been there done that eight years prior when I did work for a company that wrote field service software for ruggedized Windows CE devices and 5 years prior when I did something similar for rail car repairmen.
It also wouldn’t make sense for them to write anything that could be done with Salesforce or a third party LMS.
Software developers are a cost center to a non software company.
There's not much more I can add, but there's something I must pick on, in the name of countless users who suffer because of this:
> My answer was that I wouldn’t and went into details all of the complications of validating addresses
So far, so good...
> and that I would use 3rd party CASS software.
Why? The correct answer almost universally is: "I would not do that thing, period, because it's a lose-lose idea that hurts both you and your customers". Same with validating people's names.
EDIT: Since downthread you mention it was a system "for a health care company that sent at home nurses to special needs kids", part of which involved said nurses doing data entry... I wonder how much those nurses loved the address validation "feature" and how many serious issues (as in, with actual consequences to someone's health) it caused.
For a lot of industries, bulk address verification is a requirement to get a cheaper mailing rate. I first started using it when I was working for a SaaS company that printed and mailed bills and statements to customers.
It also a requirement for medical billing.
At one level I understand it. Gone are the days of us hacking away as an island, playing around, experimenting. Software engineering is more mature, boring, and corporate.
The first is those who write only code, with no regards for the overall design or documentation of the system, and are completely unable to formulate answers about the high-level functioning of the system, often ask for things based on a low-level need with no regard for what could or should happen at a high level, because nobody has the high level picture.
The other one is armchair architects who will draw system diagrams utterly disconnected from reality, with sub-systems doing things they cannot do, that we will never hire the engineering to do, etc. They'll mandate "common APIs" and "everything must be REST" (but where REST is their personal vision, which is inevitable not RESTful at all, and often is just a bespoke RPC/HTTP style API).
There's a happy medium in the middle: engineers who understand the code, can be productive in the code, but also understand and are making conscious decisions about what the highlevel should be, making design docs, emailing about intentions, etc.
Management has to offer the environment for that to flourish though: there has to be the time for documentation, the time for the design to emerge and for bugs to be worked out. But if everything is just a PM's pet ticket that is due "yesterday" and it must be done because management decrees it and once it is, repeat? Then that'll never happen, and those eng will quickly find greener pastures.
Sometimes it's really petty stuff, too. I've lost the fight of "engineering needs a mailing list to discuss technical changes, TDDs they'd like a review on, etc. There needs to be an alias for engineers to do engineering" — and yeah, no TDDs have happened since!
My current gig is basically the first one. Nobody has the big picture. Nobody wants to discuss the big picture. They are only interested in checking off the boxes associated with the task they currently have assigned. Everything is due yesterday because there is no actual priority list and our priorities shift on a daily basis. It's utter chaos.
We are writing an ERP system. It is slowly shaping up to be a complete disaster. I have spent the last eight months trying to change this approach and attempting to lead by example.
It's not working. I will be moving on soon.
TLDR: Just because somebody can afford to hire a software engineer, doesn't mean they should hire a software engineer.
Most importantly it doesn't tell us what we're not doing here, and why not.
I find myself adding comments to my own code when 6 months after the fact I'm re-discovering why something that looks casual is really important. Why that one "obvious " improvement or optimization is -not- done.
But that's documentation at the lowest level. Most of my documentation time (and I'll admit to writing a lot of docs) is about a bigger picture; hoe is the code used, what problems does it solve, how it interacts with the world and so on.
Documentation is not about writing the obvious "this increments x", its about making the code reusable, making it useful to yourself and your colleagues, my noting that it exists.
It I'd if you like the "search index" into the code.
In theory, this makes perfect sense and is a great way to amplify a more senior developer's impact compared to just coding "the hard stuff." In practice, unfortunately, this leads to a "doc culture" where there's often too much focus on the writing & documents and not enough on the coding & getting shit done.
For example, look at Amazon. Writing is considered a core SDE skill, yet atrocious code (especially from more senior "lifers") and shitty half-solutions are seemingly desirable. Promotion at Amazon is about telling a story of your impact in your promo doc, not about explaining to the powers that be that you're a kick-ass engineer who needs harder problems.
it's frustrating because capacity planning expects that all engineers / ICs write code at least 75% of their time. the effect is that titles+headcount no longer accurately reflects what are and arent reasonable deliverables / deadlines for a team.
Have you ever seen an accurate prediction of this by any methodology?
This is why in a lot of companies, internal tools (like issue trackers, performance monitoring, logging, orchestration, testing, etc) are written and rewritten over and over again. The idea that building your own is better than using off the shelf software. But it's self-gratification, it's avoiding the company's own / real problems and products.
Writing code without a plan or purpose is wasteful.
Drop any senior dev into coding duty, and their skills return after one to two weeks. On the other hand, asking a junior dev to implement a new system that integrates with 3 other departments, and you'll have to wait two quarters for them just to figure out who to talk to and how to get consensus.
If an enterprise has well defined interfaces for teams to interact with one another and effective escalation points for conflicts in priorities then communication might be the cheap & easy part.
Conversely, small modifications to a messy codebase can be extremely time consuming. Imagine being asked to fix an animation bug on an in house date picker in a large Angular app that hadn't been updated in 5 years.
I don’t see this happening within the next 24 months.
The various LLMs do very poorly at generating and implementing high level designs, especially if they need to generate the specs themselves from a bunch a requirements and/or poorly formulated user feedback.
That for sure will scale on larger projects!
I've played with code generation from AIs it works sometimes but confidently produces bugs and doesn't scale at all.
I think another giant leap is required to get to the point that humans are just tweaking. I'm saying we won't get there but what in the pipeline in the next 24 months that is going to get us there?
What I base my guess on: the fact we already have GPT apps that write apps and clearly it works fine, and as we like to say "this is the worst it'll ever be". When people say "it's not very good right now, it produces garbage" I only see people who are not used with the speed of progress right now. Midjourney a year ago produced weird abstract doodles that only looked like images from distance. Now it produces photorealistic art that's taking jobs. One year.
What we need: Bigger context, expert models in constellation and scale. You need nothing else. Of course some architectural modifications will emerge in the journey of achieving this, but that's a comparatively trivial constraint to solve, it's just normal software engineering as we've done for decades, but this time for models.
Second: implementation is harder then design. If AI can do implementation it can for sure do design. And it is demonstrably true that chatGPT can do design just as well if not better than implementation.