I am really hating working in the current state of the industry right now. I am used to writing robust, clear, well-tested, and easy to maintain systems.
The job right now seems just stitching AWS services together, and spending the rest of your time debugging and putting out fires.
The lie we tell ourselves is that the quality of code matters to non-engineers. It seems it doesn't.
The most uncomfortable truth of our field is that there is no floor for how bad code can be, yet still make people billions of dollars.
Because that's the outcome everyone else is seeking - making money. They don't care how good the code is. They care about whether it's making money or not.
Well, you're not saying it right. When a non-programmer (and even some programmers) hear "bad code", they start thinking in terms of aesthetics. In fact, "bad code" is sometimes just called "ugly code", making the analogy worse. Fast, responsive code is probably "ugly" to some people, but beauty is in the eye of the beholder. Maintainable code is so verbose as to be considered "bad" to some on first glance, but proves its worth when the requirements change. Rather than talk about code quality, we should be harping on product quality, which can only be achieved through consistent software (dare I say?) engineering practices - which, if followed consistently and unapologetically, will accidentally lead to "good" code.
Haha the non-engineers at my place don’t care at all about code quality.
The non-engineers also decided to write their own internal tool, with no review and zero attention to quality. It’s been outputting wrong results that will cost them a few million at least.
Reminds me of the job where we'd have huge slowdowns in our massive SQL Cluster because some non-engineers in "R&D" "had" to run unoptimized, barely legible Access queries against it.
We eventually had to create a replica of Production specifically for such nonsense.
Well then we moved a lot more business logic that they "helped develop" that ran on a distributed platform closer to "real time" for the application, because it was very dynamic in nature, and couldn't be denormalized back into the DB and remain performant. So I had to build a new system for some of their ad hoc queries and teach them how to use it.
What eventually chuffed me was realizing the "R&D" person I was "training" on the system always wore a different three piece suit every day and at least in fashion signals was probably making a magnitude higher salary than me for slower, wronger answers than any system I worked on, but probably was great at throwing it (very slowly) into very fancy graphs in Excel and useless salesmanship.
There were a lot of reasons I already wasn't long for that job at that point, but that was a lasting lesson that quality and performance won't matter to certain styles of upper management.
I have totally accepted the fact that quality of code does not matter to stakeholders. That actually makes sense. No one got an infusion of VC money because they used Node and the LATEST libraries. They don't care what's under the hood.
What bothers me is that robustness and maintainability of code no longer seems to matter to engineers.
Believe me, the pressure right now to deliver working code no matter what is much less than, say, in early 2000's, when web development was very new and few people knew what they were doing.
You try to explain the importance of testing and good code quality to your higher ups only to be retorted with "but we need this to be out in X weeks!".
And then when a production bug is revealed, they then angrily ask "why are these errors occurring?"
Managers getting taken advantage of by allowing people to do anything in the name of 'technical debt' 'code quality', resulting in more bugs, lots of needless refactoring, tons of layers of abstraction and tests that actually do close to nothing.
Result is they are then surprised it takes a long time to develop new features where competitors do it faster and eat their lunch.
There needs to be some sort of balance, companies need to make money to allow for proper code to be developed, second is also valuable as long as it makes sense financially as well.
> allowing people to do anything in the name of 'technical debt' 'code quality', resulting in more bugs, lots of needless refactoring, tons of layers of abstraction and tests that actually do close to nothing.
This heavily points to dysfunctional development team with fault being primary on tech leads making more and more mess the more they code.
> companies need to make money to allow for proper code to be developed, second is also valuable as long as it makes sense financially as well.
This one is merely about putting less resources on development. I don't think it fixes the dysfunctional team above, it is just avoid the issues. There is nothing that would make developers write useful tests. Nothing that would change tech leads, nothing that would prevent unmaintainable code appearing again.
Had the constantly refactoring team ended with very good code for too much of price, then cutting resources is likely to lead to better trade off. But that is not their case, their case is that they don't know how to write good code.
> This heavily points to dysfunctional development team with fault being primary on tech leads making more and more mess the more they code.
You are correct.
> I don't think it fixes the dysfunctional team above, it is just avoid the issues.
Sometimes avoiding the issues is good. My point is that some developers cry wolf too often, focusing them on solving problems and shipping features may yield better results.
I have always wondered if there can be an AWS for employees.
X1 dev, X1 designer, e2 manager, etc. You can autoscale your company through jira integration.
You will save on health insurance, benefits, unproductive time, salaries etc. Only aws will need to cover that but those employees can work and scale for hundreds of companies monthly.
You can have your own college and production line for people out of school so you can grade.
"dev", "designer", "manager", etc. aren't interchangeable machines in the same way that compute instances are; they're human beings! Would you personally work for this "AWS for employees", with no job security, with no consistent working relationships with other people, with no knowledge of why you are doing the things you are tasked besides "the algorithm said I must do it, so I do it"? I know I wouldn't.
Fortunately, this is a horrible idea that has essentially zero chance of becoming reality, as things like stable work relationships and a sense of purpose boost productivity, making employees more productive per unit labor cost than a Mechanical Turk for making more Mechanical Turks.
This sounds like the story Manna [1] by Marshall Brain.
In the first half of the story, employees are increasingly micro-managed by a centralized software program which becomes more sophisticated and ubiquitous over time until humanity becomes fungible.
> The job right now seems just stitching AWS services together, and spending the rest of your time debugging and putting out fires.
This is exactly what our engineers do, too! I am kept motivated by what we are able to do with what we've stitched together. But yes, knowing it is a bunch of plastic garbage underneath is... depressing, almost.
I think OP is referring to things like working on cloud infrastructure, systems software like web servers and reverse proxies, programming languages, or foundational libraries and frameworks libraries—all of which are consumed by application developers
Or have my job, switching periodically between on all that stuff and the end application. Make sure the tools you make are actually useful for the problem they purport to solve!
We just refuse to use vendor-lock-in cloud crap as a matter of principle. Regular server processes (though Haskell), regular machines (the NixOS), PostgreSQL, no problem.
Must be nice, I'm surrounded by zombies that are either RDD or truly naive. Most of the ecosystem this org works with really doesn't make sense for "cloud." Most of it should be internal infrastructure for an entire host of reasons aside from occasionally using EC2 instances for special case bursts of computing demands. Instead theres an obsession with AWS with no solid rationale.
> Does this describe Unix, for example? In particular the old AT&T version, not GNU
At least to me. Having all these composable commands, unimaginable through how many iterations all that stuff went. I also think that Go was created in that spirit, with robustness/conciseness being more important than anything. Although it seems the language and its philosophy is adapting to more common ways of doing things.
It seriously came as condescending since I'm quite removed from HN bubble. At least you warned me, thanks.
My comment is not about the norm but about the nature of the work structure. See I've mostly been working in average (non IT) places. I can understand average salesman and clerks having troubles organizing, dealing with computer issues, bad software, and cracking under managers because they don't have Masters degrees in abstract algebra applied to relational databases. So I assumed that in an IT company the skills would influence the structure. I guess it boils down to low level politics as usual.
Sorry English isn't my mother tongue, so I didn't see a way to make it short and not condescending hence the warning.
May I interest you in one of my earlier comment to show you how dysfunctional a company can be (to put things in perspective : my boss was a software engineer before becoming the boss, our company has something like 25 millions € per year and the certificate should cost a few hundred euros) : https://news.ycombinator.com/item?id=24220464
Governance and lack of a dictator with sane "technical debt to income" ratio. Unless you're NASA, you're not going to get there with a smart committee. You need a single person that can make the right technical decision 80% of the time and business decision 120% of the time.
Definitely the case, people don't realize how much a weak link in the chain can break the whole structure, and just how much influence the command structure can have. I've worked places where all my peers were very smart and well-qualified and still ended up outputting what boils down to smart trash because a middle manager somewhere refused to allow them to structure things well. Conway's Law isn't dependent on the group's collective IQ.
A little sensitive on this due to a recent experience where I was hired and given "ownership" only to have my very modest proposals for changes shot down if not just entirely ignored. Some "ownership"!
The result is clear, obvious code anyone can step into that is never optimized or tuned much for performance because you know some green college grad might be the person who inherits the code and you'll be under some other project's deadline and unable to help them figure out anything optimal, so it's left simple and obvious.
The job right now seems just stitching AWS services together, and spending the rest of your time debugging and putting out fires.