> In fact, a reliable engineer ought to be comfortable working on products people hate, because engineers work for the company, not for users.
I prefer to take pride in my work. This sounds like hiding ones neck to collect a paycheck.
I prefer to have hard discussions about pivoting or making changes so that we can improve the product, or company, for our users. Anything less is simply "not doing the job", or at least making a serious consession, in my opinion.
Along our career we often make compromises. I don't on something hostile to users but I surely stopped having pride on my work, partly to keep collecting a paycheck. Management, team dynamics.. are all influencing the path your product will take. Politics, economics are all factors in this too, few years ago people could jump ship easily, now a lot less so.
I'm coping through HN Hiring threads to find additional gigs that align with the need to contribute for others with less constraints.
This applies to more than just product engineering. Part of one of my former jobs (retired now) involved writing marketing copy and news releases. I never quite got over how one of my bosses, who would also write some of this material, often told visitors or other company execs that, where our textual output was concerned, “We have no pride of authorship here.” Speak for yourself, I always wanted to tell him, but never did because I needed the paycheck.
Interestingly, he lasted there only a year while I made it to nearly 17 years. Go figure.
thanks a lot for the story. I used to spend a lot of time trying to figure out how to create work groups that didn't force people into hiding their true needs, pride, creativity and efforts... but I really didn't have a minute left to pursue that goal. I know that some groups have healthier culture where people can live and work in a happy mental place .. but it seems they are a rare kind of exception.
Saying that "engineers work for the company" is a very reductionist take, taking away personal conscience, judgement and moral compass, leaving only "get in, do work, collect reward, go home" cycle. This what robots do. This is what algorithms do. Humans shall and are much more than that.
When I was the tech lead of a Linux distribution, I fought my teeth to make that thing work for the target audience who will be using it, and developers who wanna work and develop on this thing. It was not volunteer work either. It was my paying, day job.
This is why software devs are not professionals. A professional engineer will not sign off a bridge that he knows is liable to collapse. Software devs will build whatever dangerous immoral garbage their boss tells them to, and then rationalize it to themselves.
A professional has an obligation to a code of professional ethics that supercedes loyalty to their employer. Nothing of the sort exists in software.
A licensed engineer who signs off on a bridge that collapses will not remain an engineer, and may be open to criminal prosecution. Their employer knows that, and therefore doesn’t ask them to make that choice. In the rare cases where they do, the engineer doesn’t end up blacklisted across the industry for saying no.
You're mixing up the words engineer and professional.
A professional can still be a mere subordinate who just follows orders.
I don't know why it's so poulpular to conflate the word engineer and developer to the point where simonw decided to drop the most important word "software" and started calling AI assisted software development "agentic engineering" which is the most absurd oxymoron you can come up with.
The person prompting for code is delegating the majority of decision making to the AI. This is the antithesis of engineering. Hence the operator cannot be the "engineer", at best the AI can be the "engineer", if it is smart enough.
The word engineering implies a task with trade offs, guarantees and expectations about the finished product. The vast majority of software isn't important enough to even know what the specifications are or what features it should have ahead of time. You throw something at the wall and see what sticks. "Agentic engineering" just accelerates the process of throwing things onto the market.
Then there is the fact that "engineering" has become a euphemism for software and nothing else. Anything physical is excluded from the start.
Finally "agentic engineering" implies that you're engineering the agent, but you're not doing that either. You're just a user who set up a sandbox and is letting the AI loose.
Engineers are only one type of professional: doctors, lawyers and accountants are also professionals who have obligations to their profession before their obligation to their employer.
The title 'software developer' is correct. We are not engineers and we are not professionals. Pretending otherwise is a grasp for unearned status.
I believe software developers don't have any kind of paperwork to be considered professionals. Professionalism is a kind of attitude to begin with and can be tied to your conscience and moral compass.
Any paperwork certifying this is just a label and external anchor. In essence, it starts from within.
Some skilled jobs are called professions, and this special label indicates that they are more than merely jobs. The professions involve a special set of services to society, and people who join these professions are expected to uphold high ethical standards in their professional conduct.
Although many professionals have their own private businesses, and many others are employed by businesses, these occupations are misunderstood if we equate them with businesses. In fact, the growing tendency to treat professional work as nothing more than a paid jobs is the source of many ethical challenges.
- The primary goal of a business is to make a profit for the owners, and it does this by providing some product or service to customers.
- The basic purpose of a profession is to provide a service to the community. Here, the primary goal is societal well-being, not profit.
This distinction reflects a higher level of responsibility, expertise, and commitment to maintaining standards that sets professions apart from other occupations.
But... what if the users are mere vessels and true users are actually the people paying for it. I am saying it half-jokingly having watched big short. I dunno man. I know by now I have a line, but I know that line differs from person to person.
To your point, some of this stuff is loosely defined its no small wonder management is able to play word games.
When your code uses inversion of control, which can allow your code to inject different versions of your dependencies, such as a mocked disk API, or network resource, the code is often more testable because of the separation of concerns, and thoughtful design.
I would answer your question by stating your alternative _might_ be an easier test to write now, but amortizing the (already low) cost of having a code written with first practices in mind will be much easier to work with in the long run. Including across small and large teams. Ultimately we want our code to be reliable and scalable, and we can do that by making our code testable and maintainable.
You can of course test the UI by just reporting the file system to be full, but when you want to test your low-level stuff you would be resorting to faking syscalls. That is of course doable, but why do that when you can just create the situation directly.
Let's not pretend that firing software engineers for reading a publicly available Slack list with software is anything but the crack of a whip. Or equivocate doing that with firing _700 people_ while the board gets their million-dollar yacht bonuses.
Remember back when they built these businesses out of thin air, they would hire for the type of personality that would hack together something pointless like this.
This was a great read, even without having been working with Go for some time. It was well written, the examples demonstrated nearly everything, and being able to edit samples to test everything else, all on my phone, is quite delightful. Cheers to the author
I'm guessing contracts for the existing sludge need to expire first before they improve their product.
reply