The solution usually isn't "better people." It's engaging people on the same goals and making sure each of them knows how their part fits with the others. It's also recognizing when hard stuff is worth doing. Yeah you've got a module with 15 years of tech debt that you didn't create, and no-one on the team is confident in touching anymore. Unlike acne, it won't get better if you don't pick at it. Build out what that tech debt is costing the company and the risk it creates. Balance that against other goals, and find a plan that pays it down at the right time and the right speed.
How to do that? Genuine question.
You don't need to be anywhere close to exact, it's just helpful to know whether it costs more like 5 hours a year or 5 weeks a year. Then you can prioritize tech debt along with other projects.
But - sometimes drastic measures and hurt feeling are needed to break out of a bad attractor. Just be sure you’re OK with leaving the company/org if your play does not succeed.
And know that as the OP describes, it’s a lot about politics. If you convince management that there is a problem, you have severely undermined your technical leadership. Game out how that could unfold! In a small company maybe you can be the new TL, but probably don’t try to unseat the founder/CTO. In a big company you are unlikely to overturn many layers above you of technical leadership.
The rise of AI actually is also raising (from my observations) the engineer's role to be more of a product owner. I would highly suggest engineers learn basic UI/UX design principles and understand gherkin behavior scenarios as a way to outline or ideate features. It's not too hard to pick up if you've been a developer for awhile, but this is where we are headed.
"But what about using a message queue.."
"Candidate did not use microservices.."
"Lacks knowledge of graph databases.." (you know, because I took a training last week ergo it must be the solution).
I remembered our conversation well, because it left me a little confused. We were talking about handling large volumes of messages. And when I said "well it really depends on the volume, you could be fine with batch processing in many cases" he jumped on it like I had never heard of a queue.
Then I offered as part of my design (and from my XP in more than 10yrs of working in products with petabyte datastores) that dealing with so many services connecting to the Data store directly could run into scale issues. He flat out rejected the claim (because that didn't fit the current system design).
Guess what we're discussing now and have spun up a whole team to complete? Forcing every micro service to use a single API rather than elasticsearch directly, because of scale.
Honestly failing candidates in an interview put of a sense of superiority is just about saddest thing I've heard. I mean how lonely do you have to be ?
/endrant.
There's a small but substantial number of engineers out there who haven't operated at the kinds of scales where hyperscalers' limits become normal architectural problems and don't have the humility to imagine that it could be the case. (e.g. blob stores do in fact have limits you can hit, and when you operate at petabyte scales you have to anticipate in the architecture that you can hit them for even trivial operations.) I also work on petabyte datastores and have encountered a bunch of those engineers over time.
To be fair though, that's the small minority of engineers I've encountered, and if it wasn't arguing about the types of scale problems unique to petabyte scales, it'd be about some other nuanced subject matter. It's a humility problem.
Aso, it's crazy that an employer would yell you which individual employees voted for/against your hire.
I also think they tend to be the older ones among us who have seen what happens when it all goes wrong, and the stack comes tumbling down, and so want to make sure you don't end up in that position again. Covers all areas of IT from Cyber, DR, not just software.
When I have moved between places, I always try to ensure we have a clear set of guidelines in my initial 90-day plan, but it all comes back to the team.
It's been 50/50: some teams are desperate for any change, and others will do everything possible to destroy what you're trying to do. Or you have a leader above who has no idea and goes with the quickest/cheapest option.
The trick is to work this out VERY quickly!
However, when it does go really wrong, I assume most have followed the UK Post Office saga in the UK around the software bug(s) that sent people to prison, suicides, etc. https://en.wikipedia.org/wiki/British_Post_Office_scandal
I am pretty sure there would have been a small group (or at least one) of tech people in there who knew all of this and tried to get it fixed, but were blocked at every level. No idea - but suspect.
Simple:
1. People lost ownership of the things they work on. In the early 1900s, more than half of the workforce was self-employed. Today, it is 10% in the US, 13% in the EU.
What you produce is not “yours”, it’s “your employer’s”. You don’t have ownership, and very limited to no agency.
2. People lost any tangible connection to the quality and quantity of their output.
Most workers don’t get rewarded for working harder and producing more or better output. On the contrary, they are often penalized with more and/or harder work.
To quote Office Space: “That makes a man work just hard enough not to get fired.”
3. People lost their humanity. They are no longer persons. They are resources. Human resources. And they are treated like it.
They are exploited for gain and dumped when no longer needed.
It says early 1900s, so no. It does largely refer to farming, but farming was insanely lucrative during that time. Look at the farms that have the houses of that era standing on them and you'll soon notice that they are all mansions.
Remember, subsistence farming first had to end before people could start working off the farm. Someone has to feed them too. For 50% of the workforce to be working a job off the farm, the other 50% being subsistence farmers would be impossible.
Those are usually large plantations, and the people who owned them weren't just farmers but vast landholders with very low paid labor working the farm (at one time usually enslaved). I doubt they were representative of the typical turn of the 20th century farm.
If we're speaking from vibes rather than statistics, I'd argue most 19th century farmhouses I've seen are pretty modest. Not shacks, but nothing gigantic or luxurious.
There are no plantations around here. This was cattle and grain country in that time. Farmers got rich because all of sudden their manual labour capacity was multiplied by machines. The story is quite similar to those who used software to multiply their output in our time, and similarly many tech fortunes have built mansions just the same.
> Not shacks, but nothing gigantic or luxurious.
Well, they weren't palaces. You're absolutely right that they don't look like mansions by today's standards, but they were considered as such at the time. Many were coming from tiny, one room log cabins (stuffed to the brim with their eight children). They were gigantic, luxurious upgrades at the time. But progress marches forward, as always.
Also hard to ignore the survivorship bias there. The small/bad/ugly/whatever houses are gone.
It's not ignored. It is already encoded into the original comment. No need to repeat what is already said.
A furniture maker builds a chair, ships it out, and they don’t see it again. Pride in their craft is all about joy of mastery and building a good external reputation.
In most software jobs, the thing you build today sticks around and you’ll be dealing with it next month. Pride in your craft can be self serving because building something well makes life easier for future-you
At a high level nobody works smarter and harder than people working for themselves because they see the direct results in near linear proportion. So basically half the workforce was in that situation vs a tenth. Say nothing about taxation and other things that cost more the higher up you go and serve to fractionally break or dilute the "work harder, make more, live better" feedback loop.
It can be annoying to say, but modern factory produced things are in an absurdly higher quality spectrum than most of what proceeded them. This is absolutely no different from when machined parts for things first got started. We still have some odd reverence for "hand crafted" things when we know that computer aided design and manufactured are flat out better. In every way.
As for ownership, I hate to break it to you, but it is very likely that a good many of the master works we ascribe to people were heavily executed by assistants. Not that this is too bad, but would be akin to thinking that Miyazaki did all of the art for the movies. We likely have no idea who did a lot of the work we ascribe to single artists throughout history.
On to the rest of the points, even the ones I somewhat resonate with are just flat out misguided. People were ALWAYS resources. Well before the modern world.
In guitar manufacturing, CNC machines were a revolution. The quality of mid-range guitars improved massively, until there was little difference between them and the premium ones.
In furniture, modern manufacturing techniques drastically worsened the quality of everything. MDF and veneers are inherently worse than hand-crafted wood. The revolution here was making it cheaper.
CNC and other machining techniques raise the high bar for what's possible, and they have the potential to lower costs. That's it. They don't inherently improve quality, that's a factor of market forces.
Particularly, furniture benefits greatly from hard wood. At least, the furniture that is old that you are likely to see. It also benefits heavily from being preserved, not used.
The appropriate comparison is which is better for the same price
Lololol
Edit: I'm already down one - for people that don't read wikipedia here are the 4 dimensions of alienation of a worker as listed in the wiki:
1. From a worker's product
2. From a worker's productive activity
3. From a worker's Gattungswesen (species-being)
4. From other workers
Edit2: People [in America] will moan about their jobs, their bosses, their dwindling purchasing power, their loss of autonomy, etc etc etc but then come back as champions of capital. You see it all the time - "my job sucks but entrepreneurialism is what makes America great!!!!!!!". I've never seen a more rake->face take than this (and on such an enormous scale). It's absurd. It's delusional.
Advising on where to go from there in an actionable way that produces good results is the hard part. Marx didn't do it. Those attempting implementation of his ideas have an exceptional record and not in a good way. And worse still, some of the worst aspects of those movements are the ones that stuck around to be peddled again and again under different brands.
Lol alienation of labor is not a single "sentiment" - it's a core principle. So like it or not you share a core principle with Marx.
Worker alienation is perfectly visible on the real world. I don't think anybody disagrees it's common.
But software development is different. There has been many decades where software developers suffered very little alienation. It only changed with the universal adoption of "corporate agile".
Lol are you really gonna go with "I'm a software developer, fuck all the restaurant workers, teachers, plumbers, janitors!"
This is why Marx's ideas failed in the West - toxic individualism - and flourished in the East.
If anything happens, the company will lay off people without a care for what happens to them.
Even when they do care, such as in a smaller company, their own paycheck is being weighed against the employees, and they will almost always pick themselves, even if they caused the problems.
CEOs making millions while they lay off massive amounts of people is the norm now, and everyone knows it.
You can't blame the employee for not caring. They didn't start it.
My dad worked as an engineer in the same firm for 30 years and retired. The company was founded before his father was born, and was publicly listed before he was born.
Substantially every company I have worked for didn't even exist 30 years before I joined, let alone before I or my father were born. Most won't be around in 30 years.
Several employers nearly went out of business, had substantial layoffs, or went thru mergers that materially impacted my department/team/job. The guys at the very top were always fine, because how could the guy in charge be responsible?
Even within the companies I stayed 5 years, I had multiple roles/bosses/teams.
As a millennial kid at the time, I remember the 90's movies and sitcoms (Office Space, Friends, the Matrix, Fight Club, etc) where the biggest problem GenX had at the time was, *checks notes*, the lack of purpose from being bored out of their minds by a safe and mundane 9-5 cubicle job that paid the bills to support a family and indulge in mindless consumerism to fill the void.
Oh boy, if only we knew that was as good as it would ever be from then on.
I remember the mass layoffs Yahoo had at the dot com bubble crash, when they had a 5-15 minute 1:1 with every worker they laid off. Now you just wake up one day to find your account locked and you put it together that you got laid off, then you read in the news about mass layoffs happening while they're now hiring the same positions in India and their stock is going up.
No wonder young people now would rather just see the whole system burn to the ground and roast marshmallows on the fire, when you're being stack-ranked, min-maxed and farmed like cattle on the altar of shareholder returns.
The 80's and 90's saw the beginning of the "fuck you, got mine" mentality that pervades all but the most egalitarian societies. Reagan and Thatcher deregulated and privatized everything, and as a result a select few made a mountain of money and destroyed the middle class. "Shareholder value" and mass layoffs became the order of the day way before the dot com bubble burst. GenX knew we'd never have it as good as our parents - we just didn't know how fucked we were going to end up.
What really killed corporate loyalty for a lot of us was the lack of jobs that have lifetime pensions, if I understand it correctly. Why would I agree to work somewhere til retirement if I would be better jumping somewhere else to make more money now?
I would hope people would be more responsive to the actions of companies. Earlier in my career I looked for another company when the discrepancy between CEO bonus and employee bonus was larger than what I found reasonable.
And that exactly used to be different and still is in small companies.
My local grocery stores won’t accept pride as payment for food, and working harder doesn’t make my paycheck increase.
For individual workers, the best thing is to work @ something you love && get good pay. Like a compiler engineer, a kernel engineer, an AI engineer, etc.
Anecdotal, but I used to be proud of the work I produced, and then it got old and repetitive. However, as it was getting old, I was earning more. Now I'm in a place where if I were to quit and find something I could be proud of, I would have to accept a huge reduction in compensation. No thanks.
I'd rather have a much higher "just a paycheck" and find things to be proud of outside of work. Plus no one else cares anymore so why should I? Just pay me a lot and I'll keep showing up.
To the great surprise of my younger self I have never seen “it all come crashing down” and I honestly believe this is extremely rare in practice (i.e. the U.K post saga), something that senior devs like to imagine will happen but probably won’t, and is used to scare management and junior devs into doing “something” which may or may not make things better.
Almost universally I’ve seen the software slowly improved via a stream of urgent bug fixes with a sprinkle of targeted rewrites. The ease of these bug fixes and targeted rewrites essentially depends on whether there is a solid software design underneath: Poor designs tend to be unfixable and have complex layers of patches to make the system work well enough most of the time; good designs tend to require less maintenance overall. Both produce working software, just with different “pain” levels.
This leader is not going with the quickest or cheapest option. Doing so would probably be laudable. They are going with the claims made by someone that a certain way is going to be quicker or cheaper. It doesn't matter if it actually is, or ends up being, quicker or cheaper. One plan is classified as meeting the requirements while another plan is classified as being cheaper, the cheaper one will be chosen even though it doesn't meet the requirements.
Because there's still people doing less work than you do for a bigger paycheck
Because you'd get fired or laid off for someone working for 1/2 to 1/4th of your pay
Because they make you jump through multiple rounds of interviews and technical tests while people above you have a far less barrier to being hired
Because someone stole credit for your work
Because you'd get re-hired and find a mountain of shit code from a company that off shored their dev team
Because companies stopped giving significant raises that didn't keep up with major inflation in the past few years, while your work might have gotten them many multiples more of profits
Idk it's just a mystery we'll never know
Many employers actively discourage people from doing work that they are proud of. You cannot be proud of something that is built as cheaply as possible.
You can get employees to care about customers or the product, you cannot get employees to care about profits and dividends.
I recall there was a whistleblower Richard Roll who said that engineering did know of the bugs and flaws
What is wrong with just wanting to work for money?
> I am not sure what has happened over the decades regarding actually being proud of the work you produce.
Maybe if wages kept up with inflation people would still care. You know, when I was young, I was able to rent an apartment while being a cashier in a grocery store.
> What is wrong with just wanting to work for money?
Imagine a society where your work was an opportunity for you to provide products/services for your community, where you could earn a reputation for craftsmanship and caring, and where the real value was in the social ties and sense of social worth-- your community cares for you just as you care for it, and selfish assholery has high costs leading to poverty.
Now imagine a society where the only measure of social worth is a fiat currency, and it doesn't matter how you get it, only matters how much you have. Selfish assholery is rewarded and actually caring leads to poverty.
Which society would you rather live in? Which society is more emotionally healthy?
So the question is, is our current society the one we want to live in? If not, how do we move it closer to what we want?
By going all Ted Kaczynski on the elite and abandon sensationism and most of technology.
Socially and emotionally? It's brutal. For both the employee and society in general.
Spending almost half their waking hours not caring is not good for people.
every company in the united states could become a co-op and nothing would change for the business and everything would change for the workers. And everyone would be much happier at work and you would have the caring people you want.
It is the system that is the problem, not the people.
I expect my employees to show up to work and put forth a solid effort on a regular basis. Note that this doesn't mean a constant death march towards some unreasonable objective, or anything even close to it. Just apply yourself using the skills we agree you have for the pay we also agreed upon for 8 hours a day on average. In my field, this means you have pay that is well above the norm for an average software developer, and the working conditions are good or better.
A shocking number of people are incapable of this, and generally are also the same people who would claim that "they didn't start this".
Work being "just a paycheck" does not mean you hate it or half ass it. But, it means you do go home to get rest, you do socialize outside of work instead of irrationally pushing it and then using meetings for socialization. It means you do not have ego tied to it so much you throw temper tantrum when things are imperfect (which is not the same as being able to change things for the better).
And if you hate your job, but are completely unable to find alternative employment (which is what you should do if you hate your job), you probably should reconsider how much you hate your job.
I take pride in the stuff I enjoy doing. A job is just a paycheck because I need it.
At no point did I state or imply that workers should be working solely or even primarily for anything other than money.
But if you can't be bothered to take pride in the work you're being paid to do, you shouldn't be paid to do it for long.
Seriously, pay people what they are worth and they will care. It is not that hard.
You still can almost everywhere outside of places like SF? I just spot-checked some data, and in Minneapolis for example currently available apartments are comparable to what they were when I was looking 10 years ago, cashier wages have gone up 45%, and that often comes with healthcare benefits now. It's not an especially wealthy life, but a single person should be very comfortable (that's a comparable hourly wage and apartment cost to what I had delivering pizza at some other part of my life, and I lived comfortably and was able to save up to splurge on a nicer used Miata and the down payment for a small house).
Currently AI "solutions" being implemented in places like call centers are often technical solutions attempting to pave over organizational problems. Many IT solutions are like that. We refuse to fix the underlying problems, so we layer software on top, so we won't notice the stupidity below.
IT companies will happily take the money and write the code, broken as it might be, because the real problems aren't actually resolved. That to me is a problem. Companies needs to be way better at saying no, and offer help address the underlying issues instead, even if they aren't technical in nature.
Nothing. In fact, I envy people who can and wish I could. Consider it one of my largest flaws.
Just assume the other person knows, and avoid one extra people problem.
* Conway's law causing multiple different data science toolchains, different philosophies on model training, data handling, schema and protocol, data retention policies, etc.
* Coming up with tech solutions to try to mitigate the impact of multiple silos insisting on doing things their own way while also insisting that other silos do it their way because they need to access other silos' data.
And the reason standardization won't happen: the feudal lords of each of those branches of the hierarchy strongly believe their way is the only way that can meet their business/tech needs. As someone who gets to see all of those approaches - most of their approaches are both valid and flawed and often not in the way their leaders think. A few are "it's not going to work" levels of flawed as a result of an architect or leadership lacking operating experience.
So yeah, it might look like technical problems on the surface, but it's really people problems.
To solve this, one can be an instrument for change. Network, band people together, evangelize better ways forward, all while not angering management by operating transparently.
Sometimes, that can work... up to a point. To broadcast real change, quickly, you really need anyone managing all the stakeholders to lead the charge and/or delegate a person or people to get it done. So the behavior of directors and VPs counts a lot for both the problem and the solution. It's not impossible to manage up into that state with a lot of talking and lobbying, but it's also not easy.
I'll add that technological transformation of the workplace is so hard to do, Amazon published a guide on how to do this for AWS. As a blueprint for doing this insanely hard task, I think it holds up as a way to implement just about any level of tech change. It also hammers home the idea that you need backing and buy-in from key players in the workforce before everyone else will follow. https://docs.aws.amazon.com/prescriptive-guidance/latest/clo...
Yup, this is the key issue and what makes it primarily a people problem. Technical solutions don't work if the main problem is getting buy-in to spec/build/adopt one, unless you're willing to build a lot of things you end up throwing out. So instead the bulk of the high risk work is actually negotiation between people.
- Requirements are rarely clear from the beginning;
- We (DE) are not enabling self-service and automation so we are drowned in small requests (add this column for example;
- Upstream rarely notify us about the changes so we only know when downstream alerts us. We end up building expensive pipelines to scan and send alerts. Sometimes the cost of alerts > cost of pipeline itself;
- We have so many ad-hoc requests that sprint is meaningless. If I were the manager I'd abolish sprint completely;
- Shadow knowledge that no one bothered to write down. I tried to write down as much as possible, but there are always more unknowns than knowns;
Working in DE definitely gives me enough motivation to teach myself about lower level CS.
I work in implementation of large enterprise wide systems. When I do projects that span departments/divisions/agencies what you’re describing is the biggest hurdle. The project always starts with “we’re bringing everyone together into one solution” but as time goes on it starts to diverge. It’s so easy to end up with a project per department vs one project for all. You have to have someone with the authority to force/threaten/manipulate all the players onto the same page. It’s so easy to give in to one groups specific requirements and then you’ve opened Pandora’s box as word spreads. It’s very hard to pull off.
I think public sector (governments) is the hardest because the agencies seem to sincerely hate each other. I’ve been in requirements gathering meetings where people refused to join because someone they didn’t like was on the invite. At least in a for profit company the common denominator for everyone is keeping their job.
"The First Law of Consulting: In spite of what your client may tell you, there’s always a problem.
The Second Law of Consulting: No matter how it looks at first, it’s always a people problem." [0]
Everything he wrote is worth the time to read.
[0] Weinberg, Gerald. "The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully", 1986
> The code was calcified because the developers were also. Personality types who dislike change tend not to design their code with future change in mind.
Reasons vary widely. Code can also get calcified because people lack the vision, tech skills, or time/budget to update it. On the opposite side of the spectrum, personality types who do like change sometimes rip out everything out and start from scratch, effectively destroying well written code, which is no better.
> Why does technical debt exist? Because requirements weren't properly clarified before work began.
Not necessarily: it can also exist because code wasn't well written to begin with, libraries weren't updated to work with OS updates, feature-creep, etc.
> In my opinion, anyone above senior engineer level needs to know how to collaborate cross-functionally, regardless of whether they choose a technical or management track.
Collaboration is a skill everyone needs, and the ability to explain things to people at other levels shouldn't be limited to senior engineers. Even junior devs would do well to be able to explain things to higher-ups.
Yea, software is typically way more flexible and fast moving in the real world.
At start of project: "We need software with A, B, and C"
In middle of project: "Our competitor has released with ABCD and E, and if we don't add at least E we might as well cancel the project"
There is also - Our software works 100% fine with what we expected in the field, problem is (new|old) thing showed up and now we have to work around all the bugs in it.
Then there is Chesterton's fence. That 'broken old crap' was actually doing something highly specific that calcified into how the customers systems work. People love ripping crap up and changing stuff, until they figure out it just broke their enterprise clients workflow, and that client pays their salary.
The old system assigned work cases out in a plain round robin system - Person 1 got Case 1, Person 2 got Case 2, etc, regardless of what people already had on their plate.
The new system looked at a number of factors and assigned a new case to people who had the least amount of overall work in their queue. So if Person 1 had 2 cases and Person 2 had 10, then Person 1 was getting the next case.
Management in one division came to us after a while and said the method of assigning cases was broken, and cases were not being assigned out "fairly." They wanted us to implement the old system's round-robin assignment method in the new system.
After some investigation I determined that workers had figured out ways to game the system in order to seem more busy than they actually were and therefore receive less new cases. As a result efficient workers who were actually doing their jobs were getting punished with new cases while inefficient workers were getting rewarded.
I, another analyst from that division, and my management laid out a very clear case that if employees were not properly handling their cases, and not being monitored on their progress (by all the new monitoring tools the new system provided) then changing the method of distributing cases wouldn't fix the underlying problem.
We were overruled and forced to implement the technical solution to the human problem.
But even in the case of magically fixing people problems - for example, if you are working on a solo project - you will still have technical debt because you will still have lack of knowledge. An abstraction that leaks. A test that doesn't cover all the edge cases. A "simple" function that was not indeed that simple.
The mistake you want to avoid at all costs is believing you don't have a knowledge gap. You will always have a knowledge gap. So plan accordingly, make sure you're ready when you will finally discover that gap.
Or a lack of action. Tech breaks and you need to take the action of preparing for that.
That describes so many projects that I've seen, over the years.
One of my first programming projects, was maintaining a 100KLoC+ FORTRAN IV email program, circa 1975.
No comments, no subroutines, short, inscrutable, variables, stepped on by dozens of junior programmers, and the big breadwinner for the company.
Joy.
It was probably the single biggest motivation for my uptight coding style, since. I never want to do to others, what was done to me[0].
[0] https://littlegreenviper.com/miscellany/leaving-a-legacy/
Then the author suggests that senior leadership without a tech background will usually need to be persuaded by a value proposition - the numbers.
I'm seeing these as the same thing - the risks of specific tech debt just needs to be understood before it gets addressed. Senior leaders with a development background might be better predictors of the relationship between tech debt and its impact on company finances. Non technical leaders just require an extra translation step to understand the relationship.
Then considering that some level of risk is tolerated, and some risk is consciously taken on to achieve things, both might ultimately choose to ignore some tech debt while addressing other bits.
Outdated may sometimes be a euphemism for one of the above but usually when I see it in a discussion it just means "old" or "out of fashion" instead.
However for pretty much any dev I would hire for a job they can get to grips with a technology that's older pretty quickly. Where it does get dicey is when good dev just refuses to work with it. For those devs, I think, when they hold that opinion it typically means one of those other reasons is behind their refusal.
The irony is that this is a classic engineer's take on the root cause of technical debt. Engineers are happy to be heads-down building. But when you get to a team size >1, you actually need to communicate - and ideally not just through a kanban board.
I used to be a "stay out of politics" developer. After a few years in the industry and move to a PM role, I have had the benefit of being a bit more detached. What I noticed was that intra-developer politics are sometimes way more entrenched and stubborn than other areas of the business.
Sure, business divisions have infighting and politics but at the end of the day those are tempered by the market. It's far harder to market test Ruby Versus Java in a reasonable manner, especially when you have proponents in both camps singing the praises of their favored technology in a quasi-religious manner. And yes, I have also seen the "Why would I learn anything new, <Technology X> works for me, why would I take the effort to learn a new thing" attitudes in a large number of coworkers, even the younger Gen-Z ones.
If you're trying to pick a development language by committee, something is already very wrong. That something would be a people problem I suppose (because everything is), but it's really a strategic problem of the business.
https://www.amazon.com/Peopleware-Productive-Projects-Tom-De...
There are lots of good reasons tech debt exists, and it's worrying that this person seems to think that they all boil down to "I don't know how but someone, somewhere, fucked up"
The more interesting discussion to me is: how do you solve this problem once it exists in a team? I guess there are many approaches, but I tend to think that 'lead by the example' is the best you can do as an engineer, but a top-down approach might work better which is what happened at Microsoft when Satya Nadella became CEO.
> The code was calcified because the developers were also. Personality types who dislike change tend not to design their code with future change in mind.
This line of thinking (we will make it with future change in mind!) is of course exactly the bullshit that is tech debt in the first place.
I think this is a large factor in the turn towards more authoritarian tendencies in the Silicon Valley elites. They spent the 2000s and 2010s as a bit more utopian and laissez faire and saw it got them almost nowhere because of technology doesn't solve people problems.
Calling them 'people problem' is a convenient catch-all that lacks enough nuance to be a useful statement. What constitutes good communication? Are there cross purposes?
> Non-technical people do not intuitively understand the level of effort required or the need for tech debt cleanup; it must be communicated effectively by engineering - in both initial estimates & project updates. Unless leadership has an engineering background, the value of the technical debt work likely needs to be quantified and shown as business value.
The engineer will typically say that the communication needed is technical, but in fact the language that leadership works with is usually non-technical, so the translation into this field is essential. We do not need more engineers, we need engineer who know how to translate the details.
I realise that, here on HN, most will probably take the side of the rational technologist, but this is a self-validating cycle that can identify the issue, but cannot solve it.
IMO, we need more generalists that can speak both languages. I have worked hard to try and be that person, but it turns out that almost no-one wants to hire this cross-discipline communicator, so there's a good chance that I'm wrong about all of this.
It comes as no surprise that a worker unit who makes this conscious decision might have problems interfacing with a Homo sapiens unit.
Management claims to want to understand and fix the problem, and their "fixes" reveal the real problems. Fix 1 - schedule a lot of group meetings for twice a week. After week 1, management drops off and fails to show up anymore for most of them. The meetings go off track. The answer? More meetings!
We now have that meeting daily. And have even less attendance.
Fix 2 - we don't know what people are doing, let's create dashboards. A slapdash, highly incorrect and problematic dashboard is created. It doesn't matter, because none of the managers ever checks the dashboard. The big boss hears we are still behind, and commandeers a random product person to be his admin assistant and has her maintain several spreadsheets in semi-secret tracking everyone's progress.
This semi-secret spreadsheet becomes non-secret and people find a million and one problems with it (not surprising as the commandeered admin assistant nee product person was pulling the data from all sorts of random areas with little direction with little coordination with others). We then have the spreadsheet war of various managers having their own spreadsheets.
Fix 3 - we are going to have The Source of Truth for product intake and ongoing development, with a number of characteristics (and these are generally not terrible characteristics). These are handed off to a couple of junior people with no experience to implemented with zero feedback. The net result is we still don't have a Source of Truth, but more of an xkcd situation that now we have 4 or 5 sources of truth strung together with scripts, duct tape, bandaids and prayer.
This continues on and on over years. Ideas are put forth, some good, some bad, some indifferent, but none of them matter because the leaders lack the ability to followup or demonstrate even basic understanding of what our group actually does.
It is truly soul crushing, but in this jobs environment, what are you going to do?
I've been on both sides. Having to beg a manager to get permission to fix a thing that I thought needed fixing. And now I'm on both sides where as a CTO it's my responsibility to make sure the company delivers working products to customers that are competitive enough that we actually stand a chance to make money. And I build our product too.
Two realities:
1) Broken stuff can actually slow down a lot of critical feature development. My attitude as a CTO is that making hard things easier is when things can move forward the fastest. Unblocking progress by addressing the hardest things is valuable. Not all technical debt is created equally. There's a difference between messing with whatever subjective esthetics I might have and shit getting delayed because technical problems are complicating our lives.
2) We're a small company. And the idiot that caused the technical debt is usually me. That's not because I'm bad at what I do but I simply don't get it right 100% of the time. Any product that survives long enough will have issues. And my company is nearly six years old now. The challenge is not that there are issues but prioritizing and dealing with them in a sane way.
How I deal with this is very simple. I want to work on new stuff that adds value whenever I can. I'm happy when I can do that and it has a high impact. Whenever some technical debt issue is derailing my plans, I get frustrated and annoyed. And then I sit down and analyze what the worst/hardest thing is that is causing that. And then I fix that. It's ultimately my call. But I can't be doing this all the time.
One important CTO level job is to keep the company ready for strategic goals and make sure we are ready for likely future changes. So I look at blocking issues from the point of view of the type of change that they block that I know I will need to do soon. This is hard, nobody will tell me what this is. It's my job to find out and know. But getting this right is the difference between failing or succeeding as a technology company.
Another perspective here is that barring any technical moat, a well funded VC-funded team could probably re-create whatever you do in no time at all. If your tech is blocking you from moving ahead, it can be sobering to consider how long it would take a team unburdened by technical debt to catch up with you and do it better. Because, if the answer is "it wouldn't be that hard" you should probably start thinking about abandoning whatever you are trying to fix and maybe rebuilding it better. Because eventually somebody else might do that and beat you. Sometimes deleting code is better than fixing it.
But in seriousness it's management failure to build up debt like that. Either self management, middle management or out of touch management. There's a reason that good managers are needed. And unfortunately most management is dealing with people and/or real-world, not a fixed in stone RFC or list of vendor requirements from legal.
This might be true. But I hate it. I think I should quit software engineering.