I have a coworker who _excels_ at writing code - one of those engineers who can metabolize caffeine directly into code.
They write code to implement the all-important features. They write code to work around lack of process. They write code to work around problem people not doing their jobs well. They write code to work around buggy code by other developers. They write code to work around their own code, written weeks or months earlier.
I've been encouraging them to _reduce_ the amount of code they write, and instead consider the context around why they're writing the code. Code is just one way - and not always a particularly good way - that we can solve people and process problems.
Best Software Engineering advice I ever heard was at a conference talk by a guy called Dan North: "Think of code like surgery".
Basically Surgery is a means to an end (patient gets better) and a useful tool for achieving that but it's also dangerous so only used when necessary. If other treatments can fix the problem you try them first. If surgery is required you only do the minimum required to treat the issue.
Code is similar. More code means more maintenance, more tech debt, slower deliverables in future and higher risk of dependencies no one understands. So when coding ask "Can I fix this without code?" because if yes it's often easier in the long run and "What's the bare minimum/simplest code I need to write to fix the issue?".
I try to write as little code as possible. I do love writing code, but I've learned to love removing code even more.
The big problem in many companies is that often programmers are kept out of that context. Problems are discussed without programmers, and only tossed to programmers once non-programmers have decided what they need to do. I think we need to be more involved in those decisions.
Completely agree. This is a great insight. IMHO part of the growth of a programmer is learning how the code fits the context, and a large part of that is writing less code, not more, or getting rid of some entirely.
Not at all. Im more of an all rounder. I just like to see people matched to tasks which suit their temperament and talent.
I hate seeing people who would rather be doing customer interaction half heartedly refuctoring while people who live and breathe code sit on customer calls bored out of their minds.
I also feel a little disgusted at seeing talent wantonly squandered unnecessarily.
I'm having kind of a hard time imagining how such position would look like. Only working on greenfield projects, moving onto the next project once the codebase gets intolerable?
I wonder if the fact that we're not hired to write code, is also the reason we're not paid as much as some other roles. This is my big frustration: that senior programmers (in NL at least) are not paid as much as managers, POs, various kinds of architects, and even scrum masters.
A couple of years ago, I was freelancing for a company where I wrote a lot of excellent code. They had a bunch of data they wanted to do something with, but weren't entirely sure what or how, so I did that for them. Connected, visualized it, made it fast, and they loved it. And so did I. It was fun work, I talked to a lot of people about what they wanted and needed, and delivered that.
My freelance period ended, but I wasn't ready to leave this project yet, so I became an employee, but that turned out to be a massive step back in terms of income. Despite the fact that I worked closely with lots of stakeholders and solved complex problems for them, their internal rules didn't allow them to pay me as more than a code monkey. I felt all the non-code work I did wasn't being appreciated. Nor the code work.
I left, they ruined the application (it's apparently slow as molasses now), and now I'm about to go back. I guess I've made peace with the fact that they don't pay programmers as much as I think they should. (It's not actually bad pay, just not as much as non-programmers get.) But mostly, it was a fun project that taught me a lot, and I want more of that.
I think it's easy for the decision-makers to take programming talent for granted because they can't see it or estimate what it can do. If my manager comes to me with a task, he may not even know if the task is possible. If it turns out to be relatively simple and I kick out the solution in an hour, he's impressed, but he's also "learned" this this stuff is easier than he thought. That shifts his mental window of what's possible in X hours. Every time he thinks, "That must have been easy after all," the more he's likely to devalue what he thinks the work should cost. A smart manager will know better, but many don't.
We could combat that tendency by taking a longer time than necessary on some tasks, basically loafing to make our work look harder, but who wants to play that game?
Instead of loafing, you could also collect more context. Talk to various stakeholders to better understand the context of the problem. Read about company policies or market developments that made this necessary.
Boring stuff, I admit (the reading at least; I enjoy talking to stakeholders), but it can give you a much deeper understanding of what you're working on.
>so I became an employee, but that turned out to be a massive step back in terms of income. Despite the fact that I worked closely with lots of stakeholders and solved complex problems for them, their internal rules didn't allow them to pay me as more than a code monkey.
Surely there was a negotiation step before signing contracts? What happened there? What was the blocker that did not "allow" them to change their own internal rules that they themselves control? Surely there is a way to do that.
>I left, they ruined the application (it's apparently slow as molasses now), and now I'm about to go back
Then state what you want before going back, if it's important for them they will find a way. Don't accept these kinds of zero effort "oh our policy doesn't allow us to pay you more" explanations.
I normally do too, but in this case I did want to work there. And apparently I do again.
I negotiated my ass off, made a lot of good arguments, and everybody understood where I was coming from, but still wouldn't budge an inch. Maybe I should have walked away. In fact, I did, a couple of months later. But now I'm coming back again.
We'll see how it goes. Maybe I'll succeed at opening up higher pay scales for programmers, maybe I'll leave again after a year or so, or maybe I'll actually find happiness doing something I enjoy.
This is the general culture in Europe. Techies do not get promoted and do not even have a possibility to grow to management. Everything is run by humanities people and we do not even have the right words to describe this situation, although some voiced their concerns for many years, see e.g. The Two Cultures [1] from 1959.
> and do not even have a possibility to grow to management.
Hang on, why should this even be the goal? I really do want to question the premise of this kind of ladder in the first place. You got someone with a really good skill, one that is critical to your operations and you... want to put them in charge of people rather than keep doing what they're doing? You can just keep promoting people with whatever direction you want them to go in. It is all arbitrary and made up anyways. So why not keep promoting them in a direction where you still benefit from those technical skills?
You're also making a bad assumption. I'm just saying there should be multiple paths forward. You can promote in any direction you want as long as you decide that your employees can do that. In our fictitious scenario some could go to manage teams some not. Some could focus on their work being a team lead, some just continue doing their thing.
My point is literally at the arbitrariness of promotion and how biased it is. There's a very clear bias that being structured by business people who think business people are the most important. The classic "I do x, so x is more important" fallacy.
My point is to make people just question if what we do is actually reasonable, and if we could do things better.
Besides, I've worked with people who previously knew how to program but lost the skill when moving to management for a decade and they aren't really any better than the manager that never knew it. Neither of these results in smooth operation. But I think to see a solution we'd also need to reconsider the premise. That's what I'm getting at.
I think this is the case with real engineering companies. My wife works at Rijkswaterstaat, and there engineers bear direct responsibility for projects that are worth lives, and they can make important decisions about those projects for that reason. For example, a couple of years ago an engineer closed a bridge because of a lack of maintenance. Big scandal about the bridge getting closed, but the real scandal was that maintenance was so far behind. Turned out the engineer had warned about this several times before, but somehow those messages didn't arrive at the people in charge of planning and funding maintenance. So that was the process that really needed fixing (and the bridge, of course).
I think this is a good option. I also have no problem with experts being put in charge of people. Truthfully I think the bigger issue is that there's not more ways for growth. But at this point I'd settle for just ways to grow in the technical side without needing to move to management (being a group lead or having people under you is something I'd consider different when your main job is still doing technical work)
Techies can get into management, but they stop programming if they do. I've been told I could get into a higher pay scale if I took on managerial or administrative tasks that I'm bad at and have nothing to do with programming. I'd like to be appreciated for the stuff I'm good at, not for doing stuff I'm bad at.
I hate to break it to you, but this also happens in the US - especially at huge companies.
The next step of my career progression at my current company is deciding whether I want to go into the continuing tech route as an architect or staff software engineer or if I want to go into the managerial / people leader route.
The later is quite more lucrative, but I would have to stop programming.
Even just the existence of a staff software engineer role is something. I don't think this company has that, but I think that would be exactly what I wanted to do. Especially at this particular department.
Eng Manager here. At previous jobs I constantly had this assignment of "stop coding and only do code reviews". This to me is incredibly short-sighted as my code reviews are gonna be shit if I don't code.
Also managing a team of even 10 developers was the easiest job I ever had. Hire well, treat them well, talk with them routinely, solve conflicts, allow them to explore things.
The hard part of the job is of course functioning as a therapist for disorganised power-grabbing product people and shielding my team from their shenanigans. I'm so tired of it.
Every bad engineering manager I had two characteristics: they never have time to code but also never have to talk to me or any other employee.
European societies are extremely class based which is brutally visible in UK, France, Netherlands, even Germany. INSEAD and other MBAs see techies as washing machine repairmen.
Netherland is actually extremely egalitarian. Managers are often just one of the team, you address everybody informally, we're all equals, etc. Except in pay. And especially in larger organizations. Managers and people on track to management are seen as the shit. Programmers are paid fairly well compared to the average job, but even if you're single-handedly pulling an important project, you're never going to make the same as people who push numbers, papers and money.
> you're single-handedly pulling an important project
Never do it on employment contract in Europe. Even if you really are and then quit your job, from next Monday everything will operate as if you never had worked there.
> you're never going to make the same as people who push numbers, papers and money.
That's why the top EU companies are loathed ERP company, perfumes and purses company, and obesity drug for Americans company.
> everything will operate as if you never had worked there.
Well, they wrecked my app after I left. It was blazingly fast, and we has a very fast moving team. Now the team and the app are slow. (I don't even work there yet and I already know why it's slow, and I don't think it will be very hard to fix.)
Advice: ask for more money or don't accept an offer. They should not by any means get the message that they can keep getting away with paying smaller salaries.
In most companies, writing code is the last thing developers (should) do. You're there to achieve business objectives, and you were hired because someone thought your experience and skillset will be necessary to achieve those business objectives. Sometimes those objectives are met with an excel sheet, sometimes they're met by losely integrating various 3rd parties, sometimes they're met by integrating various libraries, and sometimes it requires treading new ground and writing some real code.
The best web dev isn't the one that knows .Net, React, Svelte, GraphQL, micro-frontends, etc. The best web dev is the one that can convince their manager that their business objectives can be achieved by using WordPress.
>The best chemical engineer isn't the one that knows the pressure at which chlorine tanks fail, they are the one that knows chlorine gas can be stored in a garage in coke bottles.
I look forward to the day that software 'engineers' are held accountable to the same degree that all other engineers are.
I've written software for industrial machinery that can kill people if it went wrong. It's amazing how much your views on software change when you realize that your accountability starts at manslaughter and goes up from there.
A human life is valued at around $10m in the developed world, incidentally my first real job was fixing an excel spreadsheet that caused $10m in trade losses after the API it called for exchange rates went stale.
I'm not saying that we arrest everyone who writes a spreadsheet to help them with their job. But _someone_ should have their head on the line when it becomes a business process without oversight that can cause millions in losses, damages or bills.
I don't think this is gonna happen until we're able to say no to stupid shit pushed on us.
When working as an electrical engineer I never had co-workers fighting me on whether I should do stuff that goes against building code. My building engineering friends never had a product manager say "trust me, we don't need this load bearing wall".
I know of engineers who did stupid shit at work and got their license revoked, and even some famous ones went to jail.
Of course there is the famous Steve Jobs story [1] where he forced Burrell Smith to do a stupid PCB and it didn't work, but Jobs was at least willing to accept that this was a test and would take the fall for the spent money.
I look forward to the day when "good code" becomes as obvious as the best practices in some other engineering disciplines.
I like the Practical Engineering YT channel and one thing I always find interesting is learning about all the research and guidance that exists for things I never thought of. Like there are 400 page documents on how to implement drainage in dams based on decades of experience and post-mortem investigations when things went wrong.
But it feels like every time I'm involved in a software project, we're starting almost from scratch and just incrementing towards an unknown future which is "good enough". Even if you have a team of experienced developers then the Best Practices at the start of the project are not what they were 2 years prior. The tools that they used on their past projects have evolved (or been deprecated). Or maybe they're being asked to do a bunch of data engineering where they previously did full stack Web development, because org structures are fluid and many IT leaders feel that good engineers can solve any problem with code (ignoring the idea of specialisation).
This is not to disagree with your point, but more to say that a lot of the infrastructure and professional norms around classical engineering disciplines just aren't there (yet) for developers.
> infrastructure and professional norms around classical engineering disciplines just aren't there (yet) for developers.
I honestly doubt it will ever get there. Our profession pretty much materialized over night in comparison to other disciplines, and in a rapidly evolving environment, with a much broader application. Only so many bridges/dams/buildings are built in a given time frame and have such incredible capital costs, and human life costs if they get it wrong. It makes sense to carefully curate who and how those things get built. The vast majority of software on the other hand, unless it is for medical/construction/factory equipment that can kill people, is usually super low stakes. And with the democratization of programming in general, even your VBA-curious business analyst can do it in their spreadsheet. Sure I can do the pro se thing in court (and lose my life/freedom), read webmd and treat my own cancer (and die), build my own dam (and flood my neighborhood), but we gatekeep those professions because of the dire consequences of fucking it up. Until software more broadly has those kinds of consequences, there will be no licensure.
I am very glad to hear the positive tone of discourse happening under your thread. I've been arguing for regulation for the software "engineering" "profession" for over a decade now, and am usually met with dramatic recoil.
You don't need to write pacemaker firmware to produce severely negative outcomes through ineptitude or indifference. I know of a frontend developer whose UX mistake in a financial mobile app triggered a vulnerable customer to end their life. I've heard stories of people ending up in the hospital because of unmet, unvoiced requirements for tasks delegated to junior developers.
It's a strange world we live in where the "profession" with the most (usually unrealized) potential has no oversight.
Bob Martin said it best: We either regulate ourselves or we will find ourselves regulated.
> chlorine gas can be stored in a garage in coke bottles
I get the point you're trying to make but you absolutely can't store chlorine gas safely in your garage in a coke bottle. If you try doing this as a business, you'll get shut down hard and possibly some prison time too.
On the other hand, WordPress is a valid solution for a huge number of businesses. Perhaps the previous commentor should have labored their point and noted that the engineer's skill is required to know when WordPress is a valid option, and also just as importantly, when it's not.
But suggesting the use of WordPress is in no way comparable to doing something illegal like storing chlorine gas improperly.
A better comparison would be to using an off the shelf chlorine storage system versus developing your own.
For most companies, off the shelf will be the right choice, but others are doing complex things that require them to develop their own systems.
I have a fairly obscure domain that gets absolutely bombarded by wordpress related scans. This tells me two things: wp seems pretty easy to misconfigure, and a lot of scripts are looking for these misconfigurations. Based solely on that I would never recommend it to a tech-naive business.
We're talking about businesses who have hired a software engineer to advise them on how to set things up correctly. I don't personally have any experience with WordPress, but I assume that it is possible to set up correctly, right? If you hire an expert and pay them to do it, I mean.
I look forward to the day when software engineers have the autonomy that licensed engineers have, so they can tell managers no and if the manager goes around the engineer, the manager and the company end up directly liable for the damage they create.
These are in fact the same thing. It is because an engineer can be held liable that results in them being willing to say no. In general, they probably won't be prosecuted, but a common reason for this is that there will be written records of engineers telling management that there are concerning risks. This also results in the job of a Professional Engineer, who is a person who legally puts themselves on the line. They get paid very well and for good reason, they have a lot on the line themselves.
I suspect that a big reason CS is not held to the same standards is due to abstraction and that it is still new. But we do live in a time where bad code can get people killed (control systems are the easiest examples), just as building a faulty bridge will. I just hope we don't need a Tacoma Bridge to cause change. Obviously it is harder to figure out things that are more abstract like Social Media (can provide both good and harm).
But I'd say, you can always say no. If you're not saying "no" now, that's still a choice you've made. A job is very persuasive, and I'm not saying you're bad for just keeping your head down, just that people should consider where they'd draw the line. The line is personal and different for everyone (which is okay!). Having taken traditional engineering courses, I'll note that ethics is frequently discussed and you're likely to be told you should try to define your line before you asked to cross it. If you don't, you'll likely to cross the line without knowing, as you just didn't know what it looked like. You can always redefine the line as you get more resolution (it continuously updates) but it's much harder to say "no" when you haven't given it much thought.
The main reason we are at a point we are is that it is possible to build very complex software systems cheaply: both the tools and building blocks are abundant and available to everyone.
If an engineer tried to build a skyscraper or a bridge, they'd meet challenges other than them having knowledge or professional certification.
And to your point, if anyone ever asked an engineer to insert another floor between 8th and 9th floor of a 15 story building, they'd laugh at them. In software engineering, this is possible even if hard.
And finally, because of software living a much different life, it will be hard to define criteria for good software.
> And to your point, if anyone ever asked an engineer to insert another floor between 8th and 9th floor of a 15 story building, they'd laugh at them. In software engineering, this is possible even if hard.
Bingo.
For building engineers this is chuckle worthy. For software engineers, it's Wednesday.
> And to your point, if anyone ever asked an engineer to insert another floor between 8th and 9th floor of a 15 story building, they'd laugh at them. In software engineering, this is possible even if hard.
Ah yes, another cocktail party idea [1] where a software engineer pretends like they understand civil engineering.
It's great when you make a general statement about somebody you are conversing with without really knowing their background.
As Dan notes himself, even scenarios which are simpler than this (moving a bridge, moving a building) are done much more rarely compared to similar requests in software. I did not accidentally use "modify something in a dimension that's really hard to modify in civil engineering" as an example — perhaps your response was a cocktail party response of someone not understanding either civil or software engineering?
IMHO, it is all about costs (which I start off with being small in software — comparatively): traditional engineering doing changes like these is extremely expensive and thus they don't (it's usually cheaper to demolish and rebuild).
I really think you should read Dan's post in full. Because you really did make the error him and Hillel discuss. I think it'll also help interpret my point and the gp to my comment. We're not thinking in a framework where CS and Eng are all that different.
Or skip to this part of Hillel's video[0]
I've been an aerospace engineer. Worked there before coming over to CS. And I can certainty tell you that yes, someone may ask you to split a floor in half. There's nothing really preventing you from doing this. There's buildings with more levels than there are ordered floors. It's a 15 floor building, but you label your floors 1-14. Such an area can be used for things like running conduit or even just as a fire break. Hell, there are even split level homes, you know those ones where you walk in the front door and either go up or down? There's also things like scissor flats.
So yeah, you are making the mistake because your example belies you. It illustrates that you aren't aware of the complexities and abstractions in the engineering job. It's okay to have only a rudimentary understanding of engineering, you've spent your time learning other things that are more valuable to you. But that doesn't mean you should assume things are simpler than they are.
The truth is that any job, has depth and far more complexity than appears at the surface. While in many jobs you can get away with only doing the simple part, there's still more depth than is actually being utilized. Likely for the same common error. You are right about cost being a big factor, but this is also a very different argument than the one about floor 8 and a half.
Again, you are making assumptions: I have read it in full, and I have experience with construction as well.
> someone may ask you to split a floor in half
Yes, I've seen it done plenty times. It's especially common with old houses which might have 4-5m high ceilings around here and people do introduce new floors in between.
Similarly, with pillars being carrying structures, it is feasible to go and turn 3 floors which are 4m high each into 4 floors ~3m high.
But while that's a way to interpret my "original ask" (and all of your examples like hidden floors and such), my intent was clear — in software, you literally go and introduce a whole new thing between the two things that were tighly coupled. Like actual structures above a certain floor.
If your implication was followed in software (i.e. try to predict the future and introduce hidden floors, service floors and such) — and it sometimes is — we really end up with worse, more complex software that has technical debt built in from the start. IOW, that's exactly not the way to build software.
Again, this does not discount the complexity of civil engineering — it is freaking hard! But my point is that it is DIFFERENT and that same approaches do not necessarily work.
> and I have experience with construction as well.
Just so we're clear, construction isn't engineering[0]. The difference does matter specifically in what we're talking about.
> If your implication was followed in software (i.e. try to predict the future and introduce hidden floors, service floors and such) — and it sometimes is — we really end up with worse, more complex software that has technical debt built in from the start.
But again, I think this belies you. Yes, I've made the assumption that you either didn't read Dan's blog in full or listen to Hillel's video, but can you blame me? This sentence is something they both explicitly discuss. You don't have everything figured out in engineering. Frequently you are doing your designs and then get them built by a manufacturer and then reiterate. This is very much akin to writing code, running tests, and rebuilding.
Hillel discusses this right here[1] (this also addresses your last line)
>> The idea that software is inheriently unpredictable and you're always doing completely new things all the time. While engineering is basically doing the same thing over and over again. Umm... yeah... so... this is probably the only question I got where people would start laughing at me when I asked it.
Or from Dan, not far in he says
>> And, of course, only someone who hasn't done serious engineering work in the physical world could say something like "The predictability of a true engineer’s world is an enviable thing. But ours is a world always in flux, where the laws of physics change weekly", thinking that the (relative) fixity of physical laws means that physical work is predictable. When I worked as a hardware engineer, a large fraction of the effort and complexity of my projects went into dealing with physical uncertainty and civil engineering is no different (if anything, the tools civil engineers have to deal with physical uncertainty on large scale projects are much worse, resulting in a larger degree of uncertainty and a reduced ability to prevent delays due to uncertainty).
I'm not interpreting your point too directly, I'm interpreting your point how you're asking I do in the followup. I am telling you the same problems happen in engineering. It is *all* about uncertainty. You are constantly doing new things that people haven't done before. In fact, the entire field of statistics is centered around uncertainty. Randomness is literally a measurement of uncertainty. Yes, it is true that in CS we don't have as formal of a base to derive complex equations and better (but not completely!) account for that uncertainty, but Dan also addresses this immediately after my quote.
In fact, let me quote from a footnote of Dan's. #2
>> When I listen to cocktail party discussions of why a construction project took so long and compare it to what civil engineers tell me caused the delay, the cocktail party discussion almost always exclusively discusses reasons that civil engineers tell me are incorrect. There are many reasons for delays and "unexpected geotechnical conditions" are a common one. ***Civil engineers are in a bind here since drilling cores is time consuming and expensive and people get mad when they see that the ground is dug up and no "real work" is happening (and likewise when preload is applied — "why aren't they working on the highway?"), which creates pressure on politicians which indirectly results in timelines that don't allow sufficient time to understand geotechnical conditions. This sometimes results in a geotechnical surprise during a project (typically phrased as "unforseen geotechnical conditions" in technical reports), which can result in major parts of a project having to switch to slower and more expensive techniques or, even worse, can necessitate a part of a project being redone, resulting in cost and schedule overruns.***
(Emphasis my own.) Does that not sound extremely familiar? Rushing for the sake of rushing? That this rushing just incurs technical debt and more surprises? There's surely the constant of management wanting things to be done faster and not recognizing that this creates future trip-ups that create more anxiety to rush and just perpetuates the problems in the first place.
> my point is that it is DIFFERENT and that same approaches do not necessarily work.
So I hope you can understand why I had thought you didn't read their arguments. I referenced the timestamp in Hillel's video[1] too. The next part of Hillel's discussion is literally about how much more predictable and consistent SOFTWARE is. *Their entire thesis* is addressing your point.
I'll leave you with Hillel again[2]
>> people like Pete McBreen and Paul Graham who say that we are not engineers because engineering cannot apply to our domain. Engineers work on predictable projects with a lot of upfront planning and rigorous requirements. Software is dynamic, constantly changing, unpredictable.
[0] I must stress that I'm not trying to say one is more important or better, just that they are different.
You've missed my entire point which is still not addressed at all with any of the examples you mention.
Please note that I never once claimed traditional engineering is predictable — you seem to be stressing a point out of your pre-conviction what a software engineer would believe and not what I am stating plainly.
I am talking about a fully "finished" project (say, an apartment building, with people living in those apartments), needing to have a floor inserted in the middle.
This is not about "changing requirements", this is about evolving a project that was initially built to be an apartment building into a stadium or an airport without messing up any of the apartment dwellers.
Again, this does not mean that the agility and creativity actual engineering needs to posess is at all smaller (in fact, some of the examples that are hard with large physical structures, are trivial with software — like that "moving a bridge" example), but I stay unconvinced that the methods that work for engineering would work as well for software.
As I believe most technical debt comes from attempting to predict the future and not rushing, I don't see the parallel there either.
Basically, they are arguing points I didn't make and don't believe, and not addressing points I do make and do believe.
> I never once claimed traditional engineering is predictable
I'm addressing this because you are stressing that software is unpredictable. You discuss this point as if it is unique to software. That is why I am pointing out that traditional engineering is highly unpredictable as well.
> I am talking about a fully "finished" project
I feel this is quite a narrow viewpoint and I'm not sure exactly how to address this. Do we consider a software project "fully finished"? I feel like you're pushing into a high level of specificity that extends outside the bounds of differentiating software engineering from traditional engineering and is more akin to differentiating software engineering from civil engineering and not from mechanical engineering. Civil engineering and mechanical engineering have different approaches, but their differences do not prevent them from being under the umbrella of "engineering". We're talking at that abstraction level. No one is attempting to claim that everything is similar between software and traditional, just as it'd be ludicrous to say that civil was the same as aerospace (try this with a bunch of aerospace folks, they'll get VERY upset). We're comparing forests, not trees. Yes, the trees make up the forest and they're different, but our discussions are about the similarities and differences in the forests.
> this is about evolving a project
Which is quite common in traditional engineering too. I've lost your point tbh. I quoted from both Dan and Hillel who address points in this direction. Are you being more specific? If so, would you elaborate? And does that level of precision even matter?
> As I believe most technical debt comes from attempting to predict the future and not rushing
While I agree that rushing isn't the only contribution to technical debt, and I even agree that over planning leads to debt, I think this is a mistake to say that rushing doesn't lead to debt. It should be clear at face value given that we all know that you don't know everything until you get into the code and working with it. Like you said, it is evolving. Meaning you learn as you're going. What's the saying? "Move fast and break things." It's a good motto but it needs an addendum: "clean up, everybody do their share." If you just blast forward to make things you're going to break things along the way. This is perfectly fine, as long as you don't leave a pile of garbage in your wake. That garbage is debt. Conversely you can spend way too much time planning and that too is debt, because as we've agreed, you don't actually know all the issues until you get your hands dirty. There's a balance here and if you're trying to put this on a binary spectrum rather than a continuum then you'll just create debt. There is no single contributing factor to technical debt, it is a multitude. A discussion of one factor is not a claim that there are no others.
I think you misinterpreted. I mostly agree. But people do program things like cars, planes, and other things that can literally cost human lives.
The judgement isn't made on if mistakes happen, but if those that built the thing should have known better. You don't get sued when you legitimately don't know, but you can't be infinitely stupid either. It's about if you should have known. This does include things like not spending enough time or research determining if something is safe, because you can't just avoid answering a question that a reasonable person would have asked. And it has to lead to harm being done.
It can help to see what the lawsuits are about. Like Takoma Airbags case[0] where they're being charged with knowing issues. It's for knowingly doing something bad. But you can't avoid asking questions, like in the Challenger Shuttle disaster[1] both NASA and Thiokol ignored signs that the O-rings being used were potentially dangerous and ignored concerns from engineers. While they didn't know the O-rings were defective in cold weather they should have known.
With more abstract stuff like Social Media, yeah, we're not in clear cases that are doing harm. No one is going to be prosecuted for inventing nor even building social media. But you can have knowingly harmful practices like manipulating users feeds without consent to perform testing to see if you can make users more happy or sad[2]. The issue isn't that the experiment happened, but that you're experimenting on humans who did not knowingly give consent. You couldn't do that type of a thing with people offline. Offline you need consent before experiments. And you can't just say they'll subject to any experimentation with no warning and grant this privilege indefinitely. Because you should be asking if your experiments might harm people and there's a reasonable belief that it might cause harm.
And on the other hand, no one is asking that the devs at wikipedia be sued or lose their programming license just because they created a dark mode where the radio button has an option of "system" but is defaulted to "light". Nor because they didn't go to the lengths is would be to make sure all images properly render when viewed in dark mode. These don't cause harm. Annoying and easy to fix issues, but no real harm has been done. Just petty issues.
It can definitely be fuzzy at certain points, especially as all this is new, but it is also okay that things become more defined over time as we learn more. The point is to keep ethics in mind and to be thinking of the consequences of your work. No one is in trouble if you don't hurt someone but you can't walk around never considering the consequences of your actions. It's the work version of not allowing an excuse of "I was just following orders" or "I was just delivering them, I didn't know what was in them". This is not some belief that people should be sued just because they wrote shitty code. But they could IF someone gets hurt AND you used AI to write code because it is cheaper than a person AND knew that the code being written could harm someone.
Developers should get the axe even though there’s an entire process behind pushing code out to production? QA, UAT? Surely people sign off on what’s being pushed out?
Worked at a SaaS company that had a fantastic product and a great tech team that had built it.
We also did a lot of data-based research and published it as white papers for lead gen.
We wanted to start publishing more content on our site to expand reach, so the team decided a CMS would be a solution for the researchers and content marketers to publish without any tech involvement.
Well it turns out our CTO, for a few justifiable reasons if we’re painting with a broad brush, absolutely loathed WordPress. So despite our arguments an integration would be easier/cheaper/less time consuming for everyone, we built our own CMS instead.
And we, of course, ended up with a significantly worse version of WordPress that the content folks all hated.
I think your model has faulty assumptions. It makes the assumptions that the companies and managers actually know what the business objectives are. Or rather, what the business objectives that will make money are. I think we all have seen examples where maybe an afternoon's worth of work could fix some feature that is frustrating users, but since there's not a clear "value" ascribed to it, it gets pushed off. While simultaneously we've seen tons of money dumped into things neither users nor investors want and that end up failing.
If we're handed an engineer title, I think we should be engineers. Which requires you to be a bit "grumpy". That is because the job of an engineer is to find problems and then fix them. I say "grumpy" because it is your job to find friction in a system and remove it. What I've often seen though is that acknowledging friction is interpreted as rejection and not as part of the process to make things better. Unless we get to the magic land of perfection, the job of identifying issues and improving will always be extremely valuable and naturally lead to increased revenue[0]. There's a lot of things that go into making a product "good" and this can't be entirely done from technical skills, but it is a critical aspect. Look at Steve Job's Apple. The genius was the mixture of form and function. You make computers that are powerful, have good software, AND the UI/UX is far from a second thought. Good UI/UX and shitty code don't make a good product, similarly neither does shitty UI/UX and impressive code (backend devs don't rule the world)
> The best web dev is the one that can convince their manager that their business objectives can be achieved by using WordPress.
Seems like your developer is a manager. This has perverse incentives and I don't think this is the right way to frame things. As an example, in law you wouldn't want a lawyer to win just because they were better at arguing. Obviously this happens and a charismatic lawyer can win despite the facts not being in their favor, but I think we all can agree that this is not what we want a justice system to look like. We want facts and the law to matter more while a lawyer's charisma (or lack of) is an unavoidable fact of life. Just a limit in the underlying mechanisms in which we communicate. Every job has politics and you can't get rid of them, but you don't want politics to rule the job. That wouldn't create the most value for the company, though it might for a person at that company.
[0] Obviously you have to weigh the costs that it takes to fix things. But identification is often cheap and easy. At least the first step of identification anyways.
I disagree with you. According to your definition of best developer, is one with a skill for persuade manager enough for building complex we apps and services? A developer is hired to write code and they achieve business goals by writing code and building software. Writing code is the skill they have and that is why they are hired.
I think it depends on your company rather than saying "most". If you are in a software company (i.e. you sell the software you write), then your value is the unique IP you create from writing code. In that case, hopefully a larger portion of your day is coding.
edit: When I say coding, I don't mean plumbing code, I mean something that is actually a unique invention.
Absolutely not. A Nascar driver isn't hired to drive to the grocery store. Or to run errands. Their not hired to drive leisurely. They're not hired to be the safest driver. They're not hired to drive the absolute highest speed either (and crash). Their hired to win races. And it's important to understand that.
The difference is that in Nascar it's very visible to everyone when a Nascar driver is driving in a way other than what they were hired for, it's not as clear for a programmer. Not to mention success as a programmer also means doing many things other than programming, including knowing when to say "we shouldn't build this".
But they're also not hired to simply "win races". You don't hire them to tinker with the car's engine, invent a tire-traction-enhancing additive, lobby for rules changes that favor your team, subcontract the driving to a better driver, or play loud music to disrupt the sleep of the opposing drivers on the night before the race. You hire them to drive the car well enough to win, because driving is the skill you hired them for.
You don't hire them to drive Ubers, sure, and likewise you want your programmers to be building things of high value. But you also don't expect them to just walk into the CEO's office, sit down in the big chair, and say "Actually, rather than writing code I can contribute more value from here, so today I'll do this job."
An academic researcher isn't hired to do research, but publish papers.
Similar to TFA, I think the issue is more about alignment than anything. Goodhart's Law creeps up slowly and can destroy any business or industry. Both can also stay off alignment for an uncomfortable amount of time. In our research example, I think it is clear we want our researcher to actually be doing research and that paper publication is a (measurable) natural result of that work, but it should be a bit more obvious to see that there are ways to increase your publication rate without increasing your research rate (or even increase your publication rate at the cost of your research rate). (Obviously I disagree with TFA's point)
The driver helps create revenue the car owner (often in the form of ad dollars). They may do this by driving well or they may do this by dating a country superstar or starting fights with other drivers.
Sure at the end of the day driving is a big part of it, but it’s not the only thing.
There’s what, 40 cars in the Daytona 500 and 39 of them lose. Are those 39 bad at their jobs?
I don't think it's pedantic at all. Your NASCAR driver is hired to win races, not to drive. If they drive on the highway, or down to the shops, or at the track when there isn't a race (or qualifying, or testing, etc.) on, or they drive a different team's car, or their own personal car, then they might be driving but they're not doing their job. Their job is to drive that particular team's car in such a way as to (directly or indirectly) win races.
In exactly the same way, a software developer isn't just hired to write code. We're hired to solve problems. We usually do that by writing code but that's not always the right approach. If your employer told you they wanted to be able to control a Windows computer from a different computer in the next room, I hope you wouldn't start writing code, you'd just show them Remote Desktop (or VNC etc.) If your employer wanted a web dashboard for your product, you might write a bit of code, but you'd try and find some existing dashboard project with an appropriate license, and hook your product's metrics up to that. Writing code is a tool, of course, and if there's no better way to do a thing (like if you're developing a new product) then writing code is going to be necessary, but a lot of times it's a tool of last resort.
I would absolutely love for the plumber whom I hired to fix my toilet to let me know what other crap I missed in my house's plumbing. Just doing the smallest, cheapest thing to fix the toilet is sometimes desirable but if it's just going to cause issues again soon, or if there are other issues I'm not aware of, I'd better at least start planning for those!
But software engineers are tasked with solving business problems. Ofcourse writing code is part of it. But other things too, for example communicating with users to understand requirements better, which lead to a reduction in scope, which reduced the code to be written.
Or sometimes it is found that a good solution can be devised but which satisfies about 80 percent of the requirements, and it may be prudent to attempt to negotiate to remove the 20 percent requirements which cannot be satisfied.
> But software engineers are tasked with solving business problems.
i would imagine that a business owner may want to hire a business analyst to undertake such a task, rather than a software engineer. Someone ideally with domain expertise in such business problems.
A software engineer is trained to produce software, given a set of requirements. If this software engineer is also tasked with gathering these requirements, which somehow, is increasingly the case now-a-days, then he's doing more than the job of a software engineer - he's also doing the role of BA.
A lot of the times, the BA gives you wrong business requirements, and an experienced software engineer can see it's wrong by reading it, and refuse to start it until the requirements are fixed. By "wrong", I meant there is a logical contradiction, or there would be harmful logical side effects because the BA can't play out the logic in their head, or it's technically impossible, or the development effort would not be worth it (for example, replicating what Google took years to build as a nice-to-have feature for an internal tool that isn't critical to the business).
Code isn't an output, it's just the final form of requirements. The software engineer job is just going from the informal talk about the feature to the formal nature of code that implements it. Yes, you can have an experienced person that broadly strokes the direction and have another less experienced programmer implements it, but there's no clear demarcation for the separation of role.
The real output is the shipped project, and sometimes your own code is only a tiny part of it.
Handyman might be better analogue. And fixing should be either change some parts inside the toilet bowl or swap whole thing. What a software engineer would do is teardown bathroom with half a building and build a new annex with squat toilet...
More in the manner a foreman is hired to deliver cars to end customers.
A nascar driver seems like overkill, competent drivers that can deliver cars without speeding, truck drivers that can load up and move 10 cars at a time, managing a team of subcontractors who can drive on demand as needed, etc. all seem like better options.
Guess what: This has all changed with LLMs. The impact of the average developer is proportional to the amount of code they ship in a world of copilots (key word is "ship", not write) and that's why some of the staff engineers I work with have 3 concurrent Cursor projects for the same codebase in flight at the same time. These are some of the best engineers I've ever worked with and they have drank the cool-aid of volume over quality.
I'm keen to this because I maintain our CI systems and have become acutely aware of the overhead of hallucinations breaking our CI tooling in pathological ways that draw me in to diagnose. A year ago I would have to log into our CI Kubernetes cluster to diagnose a busted build that doesn't self-report failure maybe... once a month. These days it's a couple times a week. LLM based dev is both amazing in the legit force multiplier it adds to writing code as well as the way it introduces some of the most incoherent and silly ways it breaks existing conventions.
I guess the headline is correct in that we are not hired to write code anymore, instead we are hired to shepherd code now, and a lot of it. And a lot of this code we shepherd is good enough but some amount of it is bad enough to break existing processes, but that is secondary to the volume and velocity we perceive from LLM code gen.
What you're describing is the erosion of engineering and computer science in software development.
We've turned what can be an engineering discipline into code slinging. I'll say my opinion is more focused on web development ad that's been my focus for the last 8 or so years, but I don't think that's unique to web either.
I don't use LLMs to help with coding, for many reasons that likely aren't important to go into here. I ship more code than most of my colleagues and I end up chasing down fewer bugs and production regressions along the way.
I don't have any problem with devs using LLMs if it makes them more productive, though that depends entirely on how one defines productive. As you said today it generally means shipping more code and has almost nothing to do with quality, which I'm just not willing to waste my time chasing. I'll ship quality code that I understand, and its either valued by my employer or it isn't.
All bureaucracies evolve towards this state, be they governmental or otherwise. The stuff that can be automated has been. (In past times, it was automated in the sense of having clerks performing basic repetitive tasks by hand). But no complex system can be fully automated without breaking down frequently. The bureaucrats are no longer hired to carry out the basic tasks, but to fix the system when it breaks down. (In the past, they helped the clerks, or signed off on a manual override of a process).
Because the automation is invisible, all that the naive observer sees is the stuff breaking down and being fixed by hand, which looks like utter chaos. And they're always drawn to wonder if the system would work better if the people were replaced by automation. No, because new people will need to be hired to keep the new system working.
Like the average observer who says the current conditions are really just the old conditions born anew, you are conveniently ignoring rate of change and its destabilizing effects.
Presumably to crank out multiple features at the same time. After spending some time writing project rules for Cursor I've gotten it to reliably implement end-to-end CRUD operations from a simple description of the fields and functionality. It's pretty neat and surprisingly accurate but it does take time to generate on the order of ~1k LOC so I understand the desire for parallelization. If you have a well-factored codebase with loose coupling, good abstractions, etc. this should be pretty doable without them stepping on each other.
Exactly, if you are doing copilot driven dev, then you are in a feedback loop with the agent and it's easier to have multiplexed ongoing "conversations" with the agent across discrete checkouts of the same codebase than it is to ask an agent to make a change, commit, checkout another branch, wait for the context to update/become aware, ask for a change, agree to it, commit, then switch back to another context.
It's the kind of thing git worktrees was made for.
Yes the nature of employment is that you're paid to do whatever the guy paying you tells you to do. Roles and specializations are organizational tools - meaning, for the benefit of the organization, not you. There will never be an exact match between the "definition of a role" and "the work that needs to be done."
I think that we're diluting the scope too much. Not only do people get paid to solve problems, also to execute them. When we get into the non execution zones, it causes many layers of beaureaucracy that will bankrupt any respectable company.
Managementbrain's definition of a well rounded developer is also the definition of people they're trying to promote out of development. Then they look around at developers wondering why they all just don't "get it".
Probably because they took the money to change role rather than keep the job they wanted.
Thoughtful perspective on the challenges of contract work. Clear communication and well-defined scope are indeed critical. I'd add that working with clients you trust and believe in, even if it means saying no sometimes, makes a world of difference in consulting. Thanks for sharing your experiences!
This article makes many valid points, but it’s important to remember 10%~ of devs are system developers(OS, compilers, firmware, database kernels etc.) For these jobs, the code itself often IS the core product. Correctness, stability, and compatibility come first, therefore the ‘out with the old and in with the new’ mentality is much less prevalent.
While I was previously the go-to person for building new features, I was unable to contribute to the implementation of Angular due to my lack of experience with it.
was he unable or was he not allowed or simply not asked? it sounds like it could be the latter which is something i'd expect from that kind of dysfunctional company, but if he was really unable then this person should not be working as a software developer.
>Does it mean that we shouldn't write code or shouldn't try to get better at it? Not at all. When working in a team, what matters most is that the weakest developer be at the very least competent. The rest is to try to build and maintain the company's product and features.
Yes. A company doesn't exist to hire programmers who write code. Software development is a means to an end.
That's in theory, in practice a very large amount of companies only hire dev to bring jira tickets to completion where engineers are kept in a complete bubble and will never speak to a single actual customer.
I used to hear this all the time back in the early 2000's. It's far from a new idea.
The version I heard (or at least the one which stuck in my head) was "your job is not to write code, your job is to solve problems".
edit:
I wish this was more mentioned more frequently these days. I see junior developers very focused on superficial aspects of code and specific "cool" frameworks these days. Often I find myself asking "what problem does this solve? What are the trade-offs with your approach? etc." and it's just crickets. I think we have made a lot of progress with modern frameworks, tools, etc. but I also think there is something from the "old days" of programming which we have lost, which I think we should have fought a bit more to keep.
I mentor a few friends and my first question when they come to me for troubleshooting is: What's the problem you're having and what has you tried so far? Then I restrict them from talking in too specific technical terms. Instead I orient the conversation to the appropriate metaphor, and more often than not, they can see the solution by themselves (unless it's really a technical implementation issue).
The article’s argument was that the company was able to migrate away from his code quickly, so his code didn’t matter.
That’s…an argument. I think most developers, myself included, find the idea of migration to be almost impossible in many cases. The author handwaved that away too easily.
... In theory yes, but company incentive structures don't always amount to this.
If you take that too literally and act on your own initiative in ways unrelated to your job description, you may well be dismissed for circumventing upper-management decisionmaking and not staying in your lane, even if you make money for the company in the process.
Or if you make tons of money for your company doing what you were hired to do, but do so from home in violation of a mandatory RTO order, you may quickly be replaced by someone who makes less money for your company but sits in the correct cubicle.
In reality, you're not merely hired to make money for the company, you're hired to do your job, even if it's not the maximally profitable action.
The company can absolutely be wrong in their idea of how to make money, no doubt. But it's still what motivates them.
I've stepped out of my lane to make money for the company, even when explicitly told not to, but the making money part meant they overlooked my transgressions. I figured they would, as businessmen really like making money.
---
If you refuse a mandatory RTO order, you may be replaced with a less productive employee. But from a company standpoint, allowing you to violate it means others will demand it, and it may be a net loss for the company to keep you.
We are hired to support whatever closed door management agreements were made. Mostly not even made for the company goals but the managers self interest
I mean its no wonder "vibe coding" is so appealing if this is the incentives framework. Why put brainpower in if it is treated as disposable junk. Just tell the AI to vibe out some slop and move on -- "business" can't tell the difference anyway.
FWIW-- I resist this mindset, but I am sympathetic to it, I understand where it comes from. Pearls before swine and whatnot.
I have a coworker who _excels_ at writing code - one of those engineers who can metabolize caffeine directly into code.
They write code to implement the all-important features. They write code to work around lack of process. They write code to work around problem people not doing their jobs well. They write code to work around buggy code by other developers. They write code to work around their own code, written weeks or months earlier.
I've been encouraging them to _reduce_ the amount of code they write, and instead consider the context around why they're writing the code. Code is just one way - and not always a particularly good way - that we can solve people and process problems.
Best Software Engineering advice I ever heard was at a conference talk by a guy called Dan North: "Think of code like surgery".
Basically Surgery is a means to an end (patient gets better) and a useful tool for achieving that but it's also dangerous so only used when necessary. If other treatments can fix the problem you try them first. If surgery is required you only do the minimum required to treat the issue.
Code is similar. More code means more maintenance, more tech debt, slower deliverables in future and higher risk of dependencies no one understands. So when coding ask "Can I fix this without code?" because if yes it's often easier in the long run and "What's the bare minimum/simplest code I need to write to fix the issue?".
That's a really interesting metaphor. I worked with Dan years ago.
It seems like the talk was at CraftCon 15 and called "Beyond Features: rethinking agile software delivery with Dan North".
I couldn't find it, but I found a similar talk he gave at a meetup that discussed surgery: https://youtu.be/EoJFWdhv8q0?feature=shared&t=1564 or https://www.youtube.com/watch?v=lz5HBtDl-1A
I try to write as little code as possible. I do love writing code, but I've learned to love removing code even more.
The big problem in many companies is that often programmers are kept out of that context. Problems are discussed without programmers, and only tossed to programmers once non-programmers have decided what they need to do. I think we need to be more involved in those decisions.
Completely agree. This is a great insight. IMHO part of the growth of a programmer is learning how the code fits the context, and a large part of that is writing less code, not more, or getting rid of some entirely.
I'd be trying to make better use of this tendency and talent, not trying to curtail it.
you are clearly missing the point, and probably feel like you have that tendency and talent yourself
Not at all. Im more of an all rounder. I just like to see people matched to tasks which suit their temperament and talent.
I hate seeing people who would rather be doing customer interaction half heartedly refuctoring while people who live and breathe code sit on customer calls bored out of their minds.
I also feel a little disgusted at seeing talent wantonly squandered unnecessarily.
I'm having kind of a hard time imagining how such position would look like. Only working on greenfield projects, moving onto the next project once the codebase gets intolerable?
What such position? Im a little unclear on what you're asking.
I wonder if the fact that we're not hired to write code, is also the reason we're not paid as much as some other roles. This is my big frustration: that senior programmers (in NL at least) are not paid as much as managers, POs, various kinds of architects, and even scrum masters.
A couple of years ago, I was freelancing for a company where I wrote a lot of excellent code. They had a bunch of data they wanted to do something with, but weren't entirely sure what or how, so I did that for them. Connected, visualized it, made it fast, and they loved it. And so did I. It was fun work, I talked to a lot of people about what they wanted and needed, and delivered that.
My freelance period ended, but I wasn't ready to leave this project yet, so I became an employee, but that turned out to be a massive step back in terms of income. Despite the fact that I worked closely with lots of stakeholders and solved complex problems for them, their internal rules didn't allow them to pay me as more than a code monkey. I felt all the non-code work I did wasn't being appreciated. Nor the code work.
I left, they ruined the application (it's apparently slow as molasses now), and now I'm about to go back. I guess I've made peace with the fact that they don't pay programmers as much as I think they should. (It's not actually bad pay, just not as much as non-programmers get.) But mostly, it was a fun project that taught me a lot, and I want more of that.
I think it's easy for the decision-makers to take programming talent for granted because they can't see it or estimate what it can do. If my manager comes to me with a task, he may not even know if the task is possible. If it turns out to be relatively simple and I kick out the solution in an hour, he's impressed, but he's also "learned" this this stuff is easier than he thought. That shifts his mental window of what's possible in X hours. Every time he thinks, "That must have been easy after all," the more he's likely to devalue what he thinks the work should cost. A smart manager will know better, but many don't.
We could combat that tendency by taking a longer time than necessary on some tasks, basically loafing to make our work look harder, but who wants to play that game?
Instead of loafing, you could also collect more context. Talk to various stakeholders to better understand the context of the problem. Read about company policies or market developments that made this necessary.
Boring stuff, I admit (the reading at least; I enjoy talking to stakeholders), but it can give you a much deeper understanding of what you're working on.
I agree with your advice but have to remark that often times stakeholders are not open to talk to techies. I loved those who were but most weren't.
They need to maintain kayfabe, otherwise all the BAs, PMs, POs, EMs would become flight risks.
>so I became an employee, but that turned out to be a massive step back in terms of income. Despite the fact that I worked closely with lots of stakeholders and solved complex problems for them, their internal rules didn't allow them to pay me as more than a code monkey.
Surely there was a negotiation step before signing contracts? What happened there? What was the blocker that did not "allow" them to change their own internal rules that they themselves control? Surely there is a way to do that.
>I left, they ruined the application (it's apparently slow as molasses now), and now I'm about to go back
Then state what you want before going back, if it's important for them they will find a way. Don't accept these kinds of zero effort "oh our policy doesn't allow us to pay you more" explanations.
I interpret "our policy doesn't allow it" as "I don't want to work here".
I normally do too, but in this case I did want to work there. And apparently I do again.
I negotiated my ass off, made a lot of good arguments, and everybody understood where I was coming from, but still wouldn't budge an inch. Maybe I should have walked away. In fact, I did, a couple of months later. But now I'm coming back again.
We'll see how it goes. Maybe I'll succeed at opening up higher pay scales for programmers, maybe I'll leave again after a year or so, or maybe I'll actually find happiness doing something I enjoy.
I am saddened to read this. You are letting them get away with it and they'll extract completely the wrong idea out of your noble gesture.
This is the general culture in Europe. Techies do not get promoted and do not even have a possibility to grow to management. Everything is run by humanities people and we do not even have the right words to describe this situation, although some voiced their concerns for many years, see e.g. The Two Cultures [1] from 1959.
[1] https://en.wikipedia.org/wiki/The_Two_Cultures
ever work for a manager that barely understood what you do, or how it’s done? Been there, done that. Never again…
Engineers shouldn’t be _forced_ into management but the option should be encouraged if they have the aptitude for it.
You're also making a bad assumption. I'm just saying there should be multiple paths forward. You can promote in any direction you want as long as you decide that your employees can do that. In our fictitious scenario some could go to manage teams some not. Some could focus on their work being a team lead, some just continue doing their thing.
My point is literally at the arbitrariness of promotion and how biased it is. There's a very clear bias that being structured by business people who think business people are the most important. The classic "I do x, so x is more important" fallacy.
My point is to make people just question if what we do is actually reasonable, and if we could do things better.
Besides, I've worked with people who previously knew how to program but lost the skill when moving to management for a decade and they aren't really any better than the manager that never knew it. Neither of these results in smooth operation. But I think to see a solution we'd also need to reconsider the premise. That's what I'm getting at.
Nope.
I do not say that experts have to be put in charge of people instead of doing what they're doing.
I rather say that experts should be in charge of what they are doing.
I think this is the case with real engineering companies. My wife works at Rijkswaterstaat, and there engineers bear direct responsibility for projects that are worth lives, and they can make important decisions about those projects for that reason. For example, a couple of years ago an engineer closed a bridge because of a lack of maintenance. Big scandal about the bridge getting closed, but the real scandal was that maintenance was so far behind. Turned out the engineer had warned about this several times before, but somehow those messages didn't arrive at the people in charge of planning and funding maintenance. So that was the process that really needed fixing (and the bridge, of course).
I think this is a good option. I also have no problem with experts being put in charge of people. Truthfully I think the bigger issue is that there's not more ways for growth. But at this point I'd settle for just ways to grow in the technical side without needing to move to management (being a group lead or having people under you is something I'd consider different when your main job is still doing technical work)
Techies can get into management, but they stop programming if they do. I've been told I could get into a higher pay scale if I took on managerial or administrative tasks that I'm bad at and have nothing to do with programming. I'd like to be appreciated for the stuff I'm good at, not for doing stuff I'm bad at.
That's exactly the point. The expectation is that techies stop being techies if want to have a career.
This is exactly why we can't innovate in Europe.
I hate to break it to you, but this also happens in the US - especially at huge companies.
The next step of my career progression at my current company is deciding whether I want to go into the continuing tech route as an architect or staff software engineer or if I want to go into the managerial / people leader route.
The later is quite more lucrative, but I would have to stop programming.
Even just the existence of a staff software engineer role is something. I don't think this company has that, but I think that would be exactly what I wanted to do. Especially at this particular department.
Eng Manager here. At previous jobs I constantly had this assignment of "stop coding and only do code reviews". This to me is incredibly short-sighted as my code reviews are gonna be shit if I don't code.
Also managing a team of even 10 developers was the easiest job I ever had. Hire well, treat them well, talk with them routinely, solve conflicts, allow them to explore things.
The hard part of the job is of course functioning as a therapist for disorganised power-grabbing product people and shielding my team from their shenanigans. I'm so tired of it.
Every bad engineering manager I had two characteristics: they never have time to code but also never have to talk to me or any other employee.
If I ever get in that position, I want an assistant to do all the paperwork, so I'll have time to code and talk to people.
European societies are extremely class based which is brutally visible in UK, France, Netherlands, even Germany. INSEAD and other MBAs see techies as washing machine repairmen.
I think it is deeper than the theory of class struggle.
France rebuilt its educational system under Napoléon to teach science to bright kids from all backgrounds.
Fast-forward 200 years, it degraded into a system that teaches anachronistic humanities to smart and docile kids of upper middle classes.
P.S. For non-French, I am talking about the system of Grandes écoles [1]
[1] https://fr.wikipedia.org/wiki/Grande_%C3%A9cole
Netherland is actually extremely egalitarian. Managers are often just one of the team, you address everybody informally, we're all equals, etc. Except in pay. And especially in larger organizations. Managers and people on track to management are seen as the shit. Programmers are paid fairly well compared to the average job, but even if you're single-handedly pulling an important project, you're never going to make the same as people who push numbers, papers and money.
Europe is egalitarian in the surface but class-based deep down. Your word is worth as much as your title.
Of course I can't speak for every country but that's the reality.
I'm not saying that anywhere else is better, but in other places I worked there was no such illusion.
This varies a lot per country. I know Germany is a lot more hierarchical, for example. They care about titles there. Here we don't.
> informally, we're all equals, etc. Except in pay.
arguably the most important part. :) 2nd being team and company culture imo.
> you're single-handedly pulling an important project
Never do it on employment contract in Europe. Even if you really are and then quit your job, from next Monday everything will operate as if you never had worked there.
> you're never going to make the same as people who push numbers, papers and money.
That's why the top EU companies are loathed ERP company, perfumes and purses company, and obesity drug for Americans company.
> everything will operate as if you never had worked there.
Well, they wrecked my app after I left. It was blazingly fast, and we has a very fast moving team. Now the team and the app are slow. (I don't even work there yet and I already know why it's slow, and I don't think it will be very hard to fix.)
Your story feels unfinished. :(
Advice: ask for more money or don't accept an offer. They should not by any means get the message that they can keep getting away with paying smaller salaries.
In most companies, writing code is the last thing developers (should) do. You're there to achieve business objectives, and you were hired because someone thought your experience and skillset will be necessary to achieve those business objectives. Sometimes those objectives are met with an excel sheet, sometimes they're met by losely integrating various 3rd parties, sometimes they're met by integrating various libraries, and sometimes it requires treading new ground and writing some real code.
The best web dev isn't the one that knows .Net, React, Svelte, GraphQL, micro-frontends, etc. The best web dev is the one that can convince their manager that their business objectives can be achieved by using WordPress.
>The best chemical engineer isn't the one that knows the pressure at which chlorine tanks fail, they are the one that knows chlorine gas can be stored in a garage in coke bottles.
I look forward to the day that software 'engineers' are held accountable to the same degree that all other engineers are.
I've written software for industrial machinery that can kill people if it went wrong. It's amazing how much your views on software change when you realize that your accountability starts at manslaughter and goes up from there.
A human life is valued at around $10m in the developed world, incidentally my first real job was fixing an excel spreadsheet that caused $10m in trade losses after the API it called for exchange rates went stale.
I'm not saying that we arrest everyone who writes a spreadsheet to help them with their job. But _someone_ should have their head on the line when it becomes a business process without oversight that can cause millions in losses, damages or bills.
I don't think this is gonna happen until we're able to say no to stupid shit pushed on us.
When working as an electrical engineer I never had co-workers fighting me on whether I should do stuff that goes against building code. My building engineering friends never had a product manager say "trust me, we don't need this load bearing wall".
I know of engineers who did stupid shit at work and got their license revoked, and even some famous ones went to jail.
Of course there is the famous Steve Jobs story [1] where he forced Burrell Smith to do a stupid PCB and it didn't work, but Jobs was at least willing to accept that this was a test and would take the fall for the spent money.
[1] https://folklore.org/PC_Board_Esthetics.html
I look forward to the day when "good code" becomes as obvious as the best practices in some other engineering disciplines.
I like the Practical Engineering YT channel and one thing I always find interesting is learning about all the research and guidance that exists for things I never thought of. Like there are 400 page documents on how to implement drainage in dams based on decades of experience and post-mortem investigations when things went wrong.
But it feels like every time I'm involved in a software project, we're starting almost from scratch and just incrementing towards an unknown future which is "good enough". Even if you have a team of experienced developers then the Best Practices at the start of the project are not what they were 2 years prior. The tools that they used on their past projects have evolved (or been deprecated). Or maybe they're being asked to do a bunch of data engineering where they previously did full stack Web development, because org structures are fluid and many IT leaders feel that good engineers can solve any problem with code (ignoring the idea of specialisation).
This is not to disagree with your point, but more to say that a lot of the infrastructure and professional norms around classical engineering disciplines just aren't there (yet) for developers.
> infrastructure and professional norms around classical engineering disciplines just aren't there (yet) for developers.
I honestly doubt it will ever get there. Our profession pretty much materialized over night in comparison to other disciplines, and in a rapidly evolving environment, with a much broader application. Only so many bridges/dams/buildings are built in a given time frame and have such incredible capital costs, and human life costs if they get it wrong. It makes sense to carefully curate who and how those things get built. The vast majority of software on the other hand, unless it is for medical/construction/factory equipment that can kill people, is usually super low stakes. And with the democratization of programming in general, even your VBA-curious business analyst can do it in their spreadsheet. Sure I can do the pro se thing in court (and lose my life/freedom), read webmd and treat my own cancer (and die), build my own dam (and flood my neighborhood), but we gatekeep those professions because of the dire consequences of fucking it up. Until software more broadly has those kinds of consequences, there will be no licensure.
I am very glad to hear the positive tone of discourse happening under your thread. I've been arguing for regulation for the software "engineering" "profession" for over a decade now, and am usually met with dramatic recoil.
You don't need to write pacemaker firmware to produce severely negative outcomes through ineptitude or indifference. I know of a frontend developer whose UX mistake in a financial mobile app triggered a vulnerable customer to end their life. I've heard stories of people ending up in the hospital because of unmet, unvoiced requirements for tasks delegated to junior developers.
It's a strange world we live in where the "profession" with the most (usually unrealized) potential has no oversight.
Bob Martin said it best: We either regulate ourselves or we will find ourselves regulated.
> chlorine gas can be stored in a garage in coke bottles
I get the point you're trying to make but you absolutely can't store chlorine gas safely in your garage in a coke bottle. If you try doing this as a business, you'll get shut down hard and possibly some prison time too.
On the other hand, WordPress is a valid solution for a huge number of businesses. Perhaps the previous commentor should have labored their point and noted that the engineer's skill is required to know when WordPress is a valid option, and also just as importantly, when it's not.
But suggesting the use of WordPress is in no way comparable to doing something illegal like storing chlorine gas improperly.
A better comparison would be to using an off the shelf chlorine storage system versus developing your own. For most companies, off the shelf will be the right choice, but others are doing complex things that require them to develop their own systems.
I have a fairly obscure domain that gets absolutely bombarded by wordpress related scans. This tells me two things: wp seems pretty easy to misconfigure, and a lot of scripts are looking for these misconfigurations. Based solely on that I would never recommend it to a tech-naive business.
We're talking about businesses who have hired a software engineer to advise them on how to set things up correctly. I don't personally have any experience with WordPress, but I assume that it is possible to set up correctly, right? If you hire an expert and pay them to do it, I mean.
I look forward to the day when software engineers have the autonomy that licensed engineers have, so they can tell managers no and if the manager goes around the engineer, the manager and the company end up directly liable for the damage they create.
These are in fact the same thing. It is because an engineer can be held liable that results in them being willing to say no. In general, they probably won't be prosecuted, but a common reason for this is that there will be written records of engineers telling management that there are concerning risks. This also results in the job of a Professional Engineer, who is a person who legally puts themselves on the line. They get paid very well and for good reason, they have a lot on the line themselves.
I suspect that a big reason CS is not held to the same standards is due to abstraction and that it is still new. But we do live in a time where bad code can get people killed (control systems are the easiest examples), just as building a faulty bridge will. I just hope we don't need a Tacoma Bridge to cause change. Obviously it is harder to figure out things that are more abstract like Social Media (can provide both good and harm).
But I'd say, you can always say no. If you're not saying "no" now, that's still a choice you've made. A job is very persuasive, and I'm not saying you're bad for just keeping your head down, just that people should consider where they'd draw the line. The line is personal and different for everyone (which is okay!). Having taken traditional engineering courses, I'll note that ethics is frequently discussed and you're likely to be told you should try to define your line before you asked to cross it. If you don't, you'll likely to cross the line without knowing, as you just didn't know what it looked like. You can always redefine the line as you get more resolution (it continuously updates) but it's much harder to say "no" when you haven't given it much thought.
The main reason we are at a point we are is that it is possible to build very complex software systems cheaply: both the tools and building blocks are abundant and available to everyone.
If an engineer tried to build a skyscraper or a bridge, they'd meet challenges other than them having knowledge or professional certification.
And to your point, if anyone ever asked an engineer to insert another floor between 8th and 9th floor of a 15 story building, they'd laugh at them. In software engineering, this is possible even if hard.
And finally, because of software living a much different life, it will be hard to define criteria for good software.
> And to your point, if anyone ever asked an engineer to insert another floor between 8th and 9th floor of a 15 story building, they'd laugh at them. In software engineering, this is possible even if hard.
Bingo.
For building engineers this is chuckle worthy. For software engineers, it's Wednesday.
> And to your point, if anyone ever asked an engineer to insert another floor between 8th and 9th floor of a 15 story building, they'd laugh at them. In software engineering, this is possible even if hard.
Ah yes, another cocktail party idea [1] where a software engineer pretends like they understand civil engineering.
[1] https://danluu.com/cocktail-ideas/
It's great when you make a general statement about somebody you are conversing with without really knowing their background.
As Dan notes himself, even scenarios which are simpler than this (moving a bridge, moving a building) are done much more rarely compared to similar requests in software. I did not accidentally use "modify something in a dimension that's really hard to modify in civil engineering" as an example — perhaps your response was a cocktail party response of someone not understanding either civil or software engineering?
IMHO, it is all about costs (which I start off with being small in software — comparatively): traditional engineering doing changes like these is extremely expensive and thus they don't (it's usually cheaper to demolish and rebuild).
I really think you should read Dan's post in full. Because you really did make the error him and Hillel discuss. I think it'll also help interpret my point and the gp to my comment. We're not thinking in a framework where CS and Eng are all that different.
Or skip to this part of Hillel's video[0]
I've been an aerospace engineer. Worked there before coming over to CS. And I can certainty tell you that yes, someone may ask you to split a floor in half. There's nothing really preventing you from doing this. There's buildings with more levels than there are ordered floors. It's a 15 floor building, but you label your floors 1-14. Such an area can be used for things like running conduit or even just as a fire break. Hell, there are even split level homes, you know those ones where you walk in the front door and either go up or down? There's also things like scissor flats.
So yeah, you are making the mistake because your example belies you. It illustrates that you aren't aware of the complexities and abstractions in the engineering job. It's okay to have only a rudimentary understanding of engineering, you've spent your time learning other things that are more valuable to you. But that doesn't mean you should assume things are simpler than they are.
The truth is that any job, has depth and far more complexity than appears at the surface. While in many jobs you can get away with only doing the simple part, there's still more depth than is actually being utilized. Likely for the same common error. You are right about cost being a big factor, but this is also a very different argument than the one about floor 8 and a half.
https://x.com/danluu/status/1484268111687663620
[0] https://youtu.be/3018ABlET1Y?t=920
Again, you are making assumptions: I have read it in full, and I have experience with construction as well.
> someone may ask you to split a floor in half
Yes, I've seen it done plenty times. It's especially common with old houses which might have 4-5m high ceilings around here and people do introduce new floors in between.
Similarly, with pillars being carrying structures, it is feasible to go and turn 3 floors which are 4m high each into 4 floors ~3m high.
But while that's a way to interpret my "original ask" (and all of your examples like hidden floors and such), my intent was clear — in software, you literally go and introduce a whole new thing between the two things that were tighly coupled. Like actual structures above a certain floor.
If your implication was followed in software (i.e. try to predict the future and introduce hidden floors, service floors and such) — and it sometimes is — we really end up with worse, more complex software that has technical debt built in from the start. IOW, that's exactly not the way to build software.
Again, this does not discount the complexity of civil engineering — it is freaking hard! But my point is that it is DIFFERENT and that same approaches do not necessarily work.
Hillel discusses this right here[1] (this also addresses your last line)
Or from Dan, not far in he says I'm not interpreting your point too directly, I'm interpreting your point how you're asking I do in the followup. I am telling you the same problems happen in engineering. It is *all* about uncertainty. You are constantly doing new things that people haven't done before. In fact, the entire field of statistics is centered around uncertainty. Randomness is literally a measurement of uncertainty. Yes, it is true that in CS we don't have as formal of a base to derive complex equations and better (but not completely!) account for that uncertainty, but Dan also addresses this immediately after my quote.In fact, let me quote from a footnote of Dan's. #2
(Emphasis my own.) Does that not sound extremely familiar? Rushing for the sake of rushing? That this rushing just incurs technical debt and more surprises? There's surely the constant of management wanting things to be done faster and not recognizing that this creates future trip-ups that create more anxiety to rush and just perpetuates the problems in the first place. So I hope you can understand why I had thought you didn't read their arguments. I referenced the timestamp in Hillel's video[1] too. The next part of Hillel's discussion is literally about how much more predictable and consistent SOFTWARE is. *Their entire thesis* is addressing your point.I'll leave you with Hillel again[2]
[0] I must stress that I'm not trying to say one is more important or better, just that they are different.[1] https://youtu.be/3018ABlET1Y?t=1085
[2] https://www.hillelwayne.com/post/are-we-really-engineers/
You've missed my entire point which is still not addressed at all with any of the examples you mention.
Please note that I never once claimed traditional engineering is predictable — you seem to be stressing a point out of your pre-conviction what a software engineer would believe and not what I am stating plainly.
I am talking about a fully "finished" project (say, an apartment building, with people living in those apartments), needing to have a floor inserted in the middle.
This is not about "changing requirements", this is about evolving a project that was initially built to be an apartment building into a stadium or an airport without messing up any of the apartment dwellers.
Again, this does not mean that the agility and creativity actual engineering needs to posess is at all smaller (in fact, some of the examples that are hard with large physical structures, are trivial with software — like that "moving a bridge" example), but I stay unconvinced that the methods that work for engineering would work as well for software.
As I believe most technical debt comes from attempting to predict the future and not rushing, I don't see the parallel there either.
Basically, they are arguing points I didn't make and don't believe, and not addressing points I do make and do believe.
Obviously never been to floor 7 1/2[0]
[0] https://www.youtube.com/watch?v=T2Y7oo3iB40
I think you misinterpreted. I mostly agree. But people do program things like cars, planes, and other things that can literally cost human lives.
The judgement isn't made on if mistakes happen, but if those that built the thing should have known better. You don't get sued when you legitimately don't know, but you can't be infinitely stupid either. It's about if you should have known. This does include things like not spending enough time or research determining if something is safe, because you can't just avoid answering a question that a reasonable person would have asked. And it has to lead to harm being done.
It can help to see what the lawsuits are about. Like Takoma Airbags case[0] where they're being charged with knowing issues. It's for knowingly doing something bad. But you can't avoid asking questions, like in the Challenger Shuttle disaster[1] both NASA and Thiokol ignored signs that the O-rings being used were potentially dangerous and ignored concerns from engineers. While they didn't know the O-rings were defective in cold weather they should have known.
With more abstract stuff like Social Media, yeah, we're not in clear cases that are doing harm. No one is going to be prosecuted for inventing nor even building social media. But you can have knowingly harmful practices like manipulating users feeds without consent to perform testing to see if you can make users more happy or sad[2]. The issue isn't that the experiment happened, but that you're experimenting on humans who did not knowingly give consent. You couldn't do that type of a thing with people offline. Offline you need consent before experiments. And you can't just say they'll subject to any experimentation with no warning and grant this privilege indefinitely. Because you should be asking if your experiments might harm people and there's a reasonable belief that it might cause harm.
And on the other hand, no one is asking that the devs at wikipedia be sued or lose their programming license just because they created a dark mode where the radio button has an option of "system" but is defaulted to "light". Nor because they didn't go to the lengths is would be to make sure all images properly render when viewed in dark mode. These don't cause harm. Annoying and easy to fix issues, but no real harm has been done. Just petty issues.
It can definitely be fuzzy at certain points, especially as all this is new, but it is also okay that things become more defined over time as we learn more. The point is to keep ethics in mind and to be thinking of the consequences of your work. No one is in trouble if you don't hurt someone but you can't walk around never considering the consequences of your actions. It's the work version of not allowing an excuse of "I was just following orders" or "I was just delivering them, I didn't know what was in them". This is not some belief that people should be sued just because they wrote shitty code. But they could IF someone gets hurt AND you used AI to write code because it is cheaper than a person AND knew that the code being written could harm someone.
[0] https://www.justice.gov/criminal/criminal-vns/case/united-st...
[1] https://en.wikipedia.org/wiki/Space_Shuttle_Challenger_disas...
[2] https://techcrunch.com/2014/06/29/ethics-in-a-data-driven-wo...
Developers should get the axe even though there’s an entire process behind pushing code out to production? QA, UAT? Surely people sign off on what’s being pushed out?
Oh wow… the WordPress example…
Worked at a SaaS company that had a fantastic product and a great tech team that had built it.
We also did a lot of data-based research and published it as white papers for lead gen.
We wanted to start publishing more content on our site to expand reach, so the team decided a CMS would be a solution for the researchers and content marketers to publish without any tech involvement.
Well it turns out our CTO, for a few justifiable reasons if we’re painting with a broad brush, absolutely loathed WordPress. So despite our arguments an integration would be easier/cheaper/less time consuming for everyone, we built our own CMS instead.
And we, of course, ended up with a significantly worse version of WordPress that the content folks all hated.
So it goes.
I think your model has faulty assumptions. It makes the assumptions that the companies and managers actually know what the business objectives are. Or rather, what the business objectives that will make money are. I think we all have seen examples where maybe an afternoon's worth of work could fix some feature that is frustrating users, but since there's not a clear "value" ascribed to it, it gets pushed off. While simultaneously we've seen tons of money dumped into things neither users nor investors want and that end up failing.
If we're handed an engineer title, I think we should be engineers. Which requires you to be a bit "grumpy". That is because the job of an engineer is to find problems and then fix them. I say "grumpy" because it is your job to find friction in a system and remove it. What I've often seen though is that acknowledging friction is interpreted as rejection and not as part of the process to make things better. Unless we get to the magic land of perfection, the job of identifying issues and improving will always be extremely valuable and naturally lead to increased revenue[0]. There's a lot of things that go into making a product "good" and this can't be entirely done from technical skills, but it is a critical aspect. Look at Steve Job's Apple. The genius was the mixture of form and function. You make computers that are powerful, have good software, AND the UI/UX is far from a second thought. Good UI/UX and shitty code don't make a good product, similarly neither does shitty UI/UX and impressive code (backend devs don't rule the world)
Seems like your developer is a manager. This has perverse incentives and I don't think this is the right way to frame things. As an example, in law you wouldn't want a lawyer to win just because they were better at arguing. Obviously this happens and a charismatic lawyer can win despite the facts not being in their favor, but I think we all can agree that this is not what we want a justice system to look like. We want facts and the law to matter more while a lawyer's charisma (or lack of) is an unavoidable fact of life. Just a limit in the underlying mechanisms in which we communicate. Every job has politics and you can't get rid of them, but you don't want politics to rule the job. That wouldn't create the most value for the company, though it might for a person at that company.[0] Obviously you have to weigh the costs that it takes to fix things. But identification is often cheap and easy. At least the first step of identification anyways.
I disagree with you. According to your definition of best developer, is one with a skill for persuade manager enough for building complex we apps and services? A developer is hired to write code and they achieve business goals by writing code and building software. Writing code is the skill they have and that is why they are hired.
I think it depends on your company rather than saying "most". If you are in a software company (i.e. you sell the software you write), then your value is the unique IP you create from writing code. In that case, hopefully a larger portion of your day is coding.
edit: When I say coding, I don't mean plumbing code, I mean something that is actually a unique invention.
... or ones that can convince them not to use WP! (RE: matt mullenwag's breakdown/mental issues)
[dead]
In the same way a nascar driver isn’t hired to drive, but hired to win races.
Feels sorta pedantic.
Fun read nonetheless.
> Feels sorta pedantic.
Absolutely not. A Nascar driver isn't hired to drive to the grocery store. Or to run errands. Their not hired to drive leisurely. They're not hired to be the safest driver. They're not hired to drive the absolute highest speed either (and crash). Their hired to win races. And it's important to understand that.
The difference is that in Nascar it's very visible to everyone when a Nascar driver is driving in a way other than what they were hired for, it's not as clear for a programmer. Not to mention success as a programmer also means doing many things other than programming, including knowing when to say "we shouldn't build this".
But they're also not hired to simply "win races". You don't hire them to tinker with the car's engine, invent a tire-traction-enhancing additive, lobby for rules changes that favor your team, subcontract the driving to a better driver, or play loud music to disrupt the sleep of the opposing drivers on the night before the race. You hire them to drive the car well enough to win, because driving is the skill you hired them for.
You don't hire them to drive Ubers, sure, and likewise you want your programmers to be building things of high value. But you also don't expect them to just walk into the CEO's office, sit down in the big chair, and say "Actually, rather than writing code I can contribute more value from here, so today I'll do this job."
Here's a less pedantic version:
An academic researcher isn't hired to do research, but publish papers.
Similar to TFA, I think the issue is more about alignment than anything. Goodhart's Law creeps up slowly and can destroy any business or industry. Both can also stay off alignment for an uncomfortable amount of time. In our research example, I think it is clear we want our researcher to actually be doing research and that paper publication is a (measurable) natural result of that work, but it should be a bit more obvious to see that there are ways to increase your publication rate without increasing your research rate (or even increase your publication rate at the cost of your research rate). (Obviously I disagree with TFA's point)
The driver helps create revenue the car owner (often in the form of ad dollars). They may do this by driving well or they may do this by dating a country superstar or starting fights with other drivers.
Sure at the end of the day driving is a big part of it, but it’s not the only thing.
There’s what, 40 cars in the Daytona 500 and 39 of them lose. Are those 39 bad at their jobs?
I know nothing about car racing and I’ll prove it: until your comment I always vaguely assumed that the number of cars in the Daytona 500 was…500?
The 500 is the length of the race in miles. It’s 200 laps of a 2.5 mile track.
I don't think it's pedantic at all. Your NASCAR driver is hired to win races, not to drive. If they drive on the highway, or down to the shops, or at the track when there isn't a race (or qualifying, or testing, etc.) on, or they drive a different team's car, or their own personal car, then they might be driving but they're not doing their job. Their job is to drive that particular team's car in such a way as to (directly or indirectly) win races.
In exactly the same way, a software developer isn't just hired to write code. We're hired to solve problems. We usually do that by writing code but that's not always the right approach. If your employer told you they wanted to be able to control a Windows computer from a different computer in the next room, I hope you wouldn't start writing code, you'd just show them Remote Desktop (or VNC etc.) If your employer wanted a web dashboard for your product, you might write a bit of code, but you'd try and find some existing dashboard project with an appropriate license, and hook your product's metrics up to that. Writing code is a tool, of course, and if there's no better way to do a thing (like if you're developing a new product) then writing code is going to be necessary, but a lot of times it's a tool of last resort.
if you hired a plumber, and asked him to fix the toilet, you expect him to fix the toilet.
You don't expect him to tell you your whole house's plumbing sucks, you have lead pipes and to properly fix the toilet you need to replace it all.
Just do the smallest, cheapest thing to fix the toilet.
Replace 'fix the toilet' with 'writing code', for programmers.
I would absolutely love for the plumber whom I hired to fix my toilet to let me know what other crap I missed in my house's plumbing. Just doing the smallest, cheapest thing to fix the toilet is sometimes desirable but if it's just going to cause issues again soon, or if there are other issues I'm not aware of, I'd better at least start planning for those!
But software engineers are tasked with solving business problems. Ofcourse writing code is part of it. But other things too, for example communicating with users to understand requirements better, which lead to a reduction in scope, which reduced the code to be written.
Or sometimes it is found that a good solution can be devised but which satisfies about 80 percent of the requirements, and it may be prudent to attempt to negotiate to remove the 20 percent requirements which cannot be satisfied.
> But software engineers are tasked with solving business problems.
i would imagine that a business owner may want to hire a business analyst to undertake such a task, rather than a software engineer. Someone ideally with domain expertise in such business problems.
A software engineer is trained to produce software, given a set of requirements. If this software engineer is also tasked with gathering these requirements, which somehow, is increasingly the case now-a-days, then he's doing more than the job of a software engineer - he's also doing the role of BA.
A lot of the times, the BA gives you wrong business requirements, and an experienced software engineer can see it's wrong by reading it, and refuse to start it until the requirements are fixed. By "wrong", I meant there is a logical contradiction, or there would be harmful logical side effects because the BA can't play out the logic in their head, or it's technically impossible, or the development effort would not be worth it (for example, replicating what Google took years to build as a nice-to-have feature for an internal tool that isn't critical to the business).
Code isn't an output, it's just the final form of requirements. The software engineer job is just going from the informal talk about the feature to the formal nature of code that implements it. Yes, you can have an experienced person that broadly strokes the direction and have another less experienced programmer implements it, but there's no clear demarcation for the separation of role.
The real output is the shipped project, and sometimes your own code is only a tiny part of it.
Handyman might be better analogue. And fixing should be either change some parts inside the toilet bowl or swap whole thing. What a software engineer would do is teardown bathroom with half a building and build a new annex with squat toilet...
More in the manner a foreman is hired to deliver cars to end customers.
A nascar driver seems like overkill, competent drivers that can deliver cars without speeding, truck drivers that can load up and move 10 cars at a time, managing a team of subcontractors who can drive on demand as needed, etc. all seem like better options.
The jobs I've had are about figuring out what to do, modifying code, and communicating why to other people.
It's fun to create a new thing or to remove an old thing that isn't needed anymore, but that's just when you can get away with it.
Guess what: This has all changed with LLMs. The impact of the average developer is proportional to the amount of code they ship in a world of copilots (key word is "ship", not write) and that's why some of the staff engineers I work with have 3 concurrent Cursor projects for the same codebase in flight at the same time. These are some of the best engineers I've ever worked with and they have drank the cool-aid of volume over quality.
I'm keen to this because I maintain our CI systems and have become acutely aware of the overhead of hallucinations breaking our CI tooling in pathological ways that draw me in to diagnose. A year ago I would have to log into our CI Kubernetes cluster to diagnose a busted build that doesn't self-report failure maybe... once a month. These days it's a couple times a week. LLM based dev is both amazing in the legit force multiplier it adds to writing code as well as the way it introduces some of the most incoherent and silly ways it breaks existing conventions.
I guess the headline is correct in that we are not hired to write code anymore, instead we are hired to shepherd code now, and a lot of it. And a lot of this code we shepherd is good enough but some amount of it is bad enough to break existing processes, but that is secondary to the volume and velocity we perceive from LLM code gen.
What you're describing is the erosion of engineering and computer science in software development.
We've turned what can be an engineering discipline into code slinging. I'll say my opinion is more focused on web development ad that's been my focus for the last 8 or so years, but I don't think that's unique to web either.
I don't use LLMs to help with coding, for many reasons that likely aren't important to go into here. I ship more code than most of my colleagues and I end up chasing down fewer bugs and production regressions along the way.
I don't have any problem with devs using LLMs if it makes them more productive, though that depends entirely on how one defines productive. As you said today it generally means shipping more code and has almost nothing to do with quality, which I'm just not willing to waste my time chasing. I'll ship quality code that I understand, and its either valued by my employer or it isn't.
Seeing as your focus has been on web development, why should it be more like engineering?
All bureaucracies evolve towards this state, be they governmental or otherwise. The stuff that can be automated has been. (In past times, it was automated in the sense of having clerks performing basic repetitive tasks by hand). But no complex system can be fully automated without breaking down frequently. The bureaucrats are no longer hired to carry out the basic tasks, but to fix the system when it breaks down. (In the past, they helped the clerks, or signed off on a manual override of a process).
Because the automation is invisible, all that the naive observer sees is the stuff breaking down and being fixed by hand, which looks like utter chaos. And they're always drawn to wonder if the system would work better if the people were replaced by automation. No, because new people will need to be hired to keep the new system working.
Like the average observer who says the current conditions are really just the old conditions born anew, you are conveniently ignoring rate of change and its destabilizing effects.
Can you explain why they have 3 concurrent cursor projects for the same code base?
Presumably to crank out multiple features at the same time. After spending some time writing project rules for Cursor I've gotten it to reliably implement end-to-end CRUD operations from a simple description of the fields and functionality. It's pretty neat and surprisingly accurate but it does take time to generate on the order of ~1k LOC so I understand the desire for parallelization. If you have a well-factored codebase with loose coupling, good abstractions, etc. this should be pretty doable without them stepping on each other.
I assume they're trying to work on three features at the same time
Exactly, if you are doing copilot driven dev, then you are in a feedback loop with the agent and it's easier to have multiplexed ongoing "conversations" with the agent across discrete checkouts of the same codebase than it is to ask an agent to make a change, commit, checkout another branch, wait for the context to update/become aware, ask for a change, agree to it, commit, then switch back to another context.
It's the kind of thing git worktrees was made for.
Yes the nature of employment is that you're paid to do whatever the guy paying you tells you to do. Roles and specializations are organizational tools - meaning, for the benefit of the organization, not you. There will never be an exact match between the "definition of a role" and "the work that needs to be done."
I think that we're diluting the scope too much. Not only do people get paid to solve problems, also to execute them. When we get into the non execution zones, it causes many layers of beaureaucracy that will bankrupt any respectable company.
Managementbrain's definition of a well rounded developer is also the definition of people they're trying to promote out of development. Then they look around at developers wondering why they all just don't "get it".
Probably because they took the money to change role rather than keep the job they wanted.
Code is a liability. Employees are a liability. Solving problems with as little code/employees/risk/cost is the goal.
Business is a liability. Maybe society should do away with most businesses and free up capital for more useful things.
reductio ad absurdum
Thoughtful perspective on the challenges of contract work. Clear communication and well-defined scope are indeed critical. I'd add that working with clients you trust and believe in, even if it means saying no sometimes, makes a world of difference in consulting. Thanks for sharing your experiences!
This article makes many valid points, but it’s important to remember 10%~ of devs are system developers(OS, compilers, firmware, database kernels etc.) For these jobs, the code itself often IS the core product. Correctness, stability, and compatibility come first, therefore the ‘out with the old and in with the new’ mentality is much less prevalent.
Our first job is not: to code. Our first job is: not to code.
While I was previously the go-to person for building new features, I was unable to contribute to the implementation of Angular due to my lack of experience with it.
was he unable or was he not allowed or simply not asked? it sounds like it could be the latter which is something i'd expect from that kind of dysfunctional company, but if he was really unable then this person should not be working as a software developer.
>Does it mean that we shouldn't write code or shouldn't try to get better at it? Not at all. When working in a team, what matters most is that the weakest developer be at the very least competent. The rest is to try to build and maintain the company's product and features.
Yes. A company doesn't exist to hire programmers who write code. Software development is a means to an end.
That's in theory, in practice a very large amount of companies only hire dev to bring jira tickets to completion where engineers are kept in a complete bubble and will never speak to a single actual customer.
I used to hear this all the time back in the early 2000's. It's far from a new idea.
The version I heard (or at least the one which stuck in my head) was "your job is not to write code, your job is to solve problems".
edit: I wish this was more mentioned more frequently these days. I see junior developers very focused on superficial aspects of code and specific "cool" frameworks these days. Often I find myself asking "what problem does this solve? What are the trade-offs with your approach? etc." and it's just crickets. I think we have made a lot of progress with modern frameworks, tools, etc. but I also think there is something from the "old days" of programming which we have lost, which I think we should have fought a bit more to keep.
I mentor a few friends and my first question when they come to me for troubleshooting is: What's the problem you're having and what has you tried so far? Then I restrict them from talking in too specific technical terms. Instead I orient the conversation to the appropriate metaphor, and more often than not, they can see the solution by themselves (unless it's really a technical implementation issue).
if this was true, then leetcode wouldn't be the cost of admission?
Writing code may not be the ultimate objective of software developers, but it is one of the primary tools to achieve that objective.
The article’s argument was that the company was able to migrate away from his code quickly, so his code didn’t matter.
That’s…an argument. I think most developers, myself included, find the idea of migration to be almost impossible in many cases. The author handwaved that away too easily.
You're hired to make money for the company.
... In theory yes, but company incentive structures don't always amount to this.
If you take that too literally and act on your own initiative in ways unrelated to your job description, you may well be dismissed for circumventing upper-management decisionmaking and not staying in your lane, even if you make money for the company in the process.
Or if you make tons of money for your company doing what you were hired to do, but do so from home in violation of a mandatory RTO order, you may quickly be replaced by someone who makes less money for your company but sits in the correct cubicle.
In reality, you're not merely hired to make money for the company, you're hired to do your job, even if it's not the maximally profitable action.
The company can absolutely be wrong in their idea of how to make money, no doubt. But it's still what motivates them.
I've stepped out of my lane to make money for the company, even when explicitly told not to, but the making money part meant they overlooked my transgressions. I figured they would, as businessmen really like making money.
---
If you refuse a mandatory RTO order, you may be replaced with a less productive employee. But from a company standpoint, allowing you to violate it means others will demand it, and it may be a net loss for the company to keep you.
most people forget this one
In other words, software engineers need to "sell" the value of their work.
they like to call it "impact"
This is another article that largely boils down to "Some people really really like money."
We are hired to support whatever closed door management agreements were made. Mostly not even made for the company goals but the managers self interest
I mean its no wonder "vibe coding" is so appealing if this is the incentives framework. Why put brainpower in if it is treated as disposable junk. Just tell the AI to vibe out some slop and move on -- "business" can't tell the difference anyway.
FWIW-- I resist this mindset, but I am sympathetic to it, I understand where it comes from. Pearls before swine and whatnot.