The job right now seems just stitching AWS services together, and spending the rest of your time debugging and putting out fires.
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.
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.
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.
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.
just imagine if automobiles, aerospace or construction was run like that.... (hint, it was in the early days)
And then when a production bug is revealed, they then angrily ask "why are these errors occurring?"
Later "WE CAN"T PUT THIS IN FRONT OF A CUSTOMER"
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.
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.
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.
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.
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.
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.
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.
Maybe then go into the HPC/Defence/Air/Space/Masstransport-Industry, they will love you, no BS thats exacly what they want and need.
I am interested in this topic, can you elaborate? Or any thoughts from anyone?
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.
Bad metaphorical usage of the term "food chain" is an example of "office speak". Personally, I don't much like it.
I wonder if that's how the implementors of software that actually lasted for decades would describe their work or motivation.
Does this describe Unix, for example? In particular the old AT&T version, not GNU (or even modern BSD) code.
https://medium.com/programming-philosophy/eric-raymond-s-17-...
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.
"The reliability of the basic utilities from GNU and Linux were noticeably better than those of the commercial systems."
[0] ftp://ftp.cs.wisc.edu/paradyn/technical_papers/fuzz.pdf
[1] ftp://ftp.cs.wisc.edu/paradyn/technical_papers/fuzz-revisited.pdf
in a group of skilled people it can still happen
is it due to bad leadership ?
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"!
You probably should get out of the HN bubble more often, a badly organized workplace is the norm not the exception.
(I hope it doesn't come as condescending since it's not my intention)
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.
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
Dysfunctional indeed.
#revolution