Hacker News Reader

What do you propose that people that want to engage in their craft with at least a modicum of craftsmanship do?

Even if it truly weren't economical to build quality software and to use real engineering to reduce risks toward achieving that goal (realistic deadlines based on past estimation error, known unknowns in planning, evaluating and training people, scheduling refactors, avoiding defects in the planning stage, planning for the duration of components' lifetimes so you can build things and eventually replace them instead of constant myopic re-architecture) -- which I highly doubt -- who's to say we have to be motivated solely by self-interested short-term economics? If the costs are externalized, of course it's more economical to do everything as shitty as everyone can get away with. What kind of Objectivist nonsense is it to say that that's the same as correct?!

For some of us, money isn't motivating, the collective consensus isn't compelling, it's not possible to be simultaneously disengaged and productive, we find investing so much of our conscious time and effort toward something we don't value existentially frustrating and simply want our investment of time and effort to result in software of quality, as simple as trying to maximize for durable utility -- as much as possible, leaving the lives of its users better off for using it, and existing and paying that dividend for as long as possible -- (true economic value) and we find we're not allowed as the majority of managers and team mates have bought into the modern kind of myopic and psychopathic faux economics of me and now. Do you really propose that we are the ones who are wrong? If we are, what's to be done -- do we accept we aren't cut out for the rat race and go live in a van?

One of the reasons the article is so bad is that it's setting up a pile of false dichotomies, some of which you're embedding into assumptions here.

Doing stuff to serve business needs is not intrinsically bad, or opposed to craftsmanship. The whole idea of craftwork is that it serves a purpose, right? It must have an actual function, and the goal is to build a thing that serves that function well. So yes, you should absolutely build software that fulfills its purpose well. Just remember that the business is the purpose, not the software in itself.

This isn't just about economics, it's about a larger perspective. Think about the people who use your software, and every time you're thinking about what you're doing, think about how it will impact those users. Will it make their experience better, or will it just make your experience better? (If the latter, don't do it.) Will it make their experience better, but there are other things that they'd really rather have. (Ensure that you're working on the right priorities.)

A lot of the things you list as "real engineering" -- realistic deadlines, risk management -- are things that absolutely do help the users: They want to know realistically when they can expect functionality to be there so they can plan for it; they want to know what things might throw that schedule off and be kept up to date on whether they're happening. So a good workplace will use those things.

(I'd argue that some of the other items you list are actually not that beneficial, like planning for long-term evolution: The reality is that businesses evolve, and they might get a new big customer, or shift into a new line of business, that will necessitate major rewrites in the application anyway, so trying to plan for that from an engineering side is light folly. But it's mostly harmless, and sometimes helpful; and depending on your environment, maybe it would make sense.)

In particular, doing everything as shittily as possible is not beneficial to anyone. Users hate systems that flake out and don't work reliably, right? (At the same time, users might rather have a particular new feature that would save them an hour every day, rather than having you fix that one really thorny bug that's causing the system to need to be rebooted once a month. You'd rather have that, too, if you were them.)

So do stuff well, engage closely with your users and customers, think about their needs and goals, and then do the best you can to meet them, while communicating openly and honestly in a collaborative spirit, and committing as a team to high standards.

It really does work, in a way that a dedication to cynicism never will.

Maybe you're just not imagining the kinds of workplaces that we work in where we have these problems?

There are teams where the political consensus is that even considering security risks is useless - who aren't budged on that position when after violating PCI DSS and having a database full of plaintext payment card information and also having a shitty copy-pasted-from-the-internet PHP newsletter form with an SQLi have payment card info stolen and used in fraud. "They probably won't sue" so even just fixing the SQLi wasn't important to them.

There are teams where "SVN and Git are hard, so we just use Dreamweaver on the shared drive and use the built in file locking to make sure nobody steps on eachother's toes".

There are teams where plaintext FTP deployment to production sites on plaintext WIFI is standard operating procedure. I couldn't convince them to change it even after showing them the username and password in Wireshark. "Anyone in the neighborhood could steal all of our client's data." wasn't scary.

There are teams where leadership has no idea of technical realities, forms bad plans in the style of "We want to make Twitter, but for IoT thermostats" and gets to set the budget for those plans before even talking to a project manager or developer, and every initiative fails (doubly since they go over their nonsense budget, and have no nonsense customers buy into it) but it's fine because it's not like anyone will ever lose their job because they're 5 levels down from the CEO and five levels up from individual contributors in the software part of a hardware-focused fortune 500 so nobody in the C-suite understands or cares what they do and it's not consequential to the level where it shows up in shareholders reports.

There are teams where they use a CMS + custom fields features and pretend it's an MVC framework and build line of business apps with only a few models but internal storage abstraction of the CMS and custom field feature blows that up into hundreds of tables with mutiple-tens-of-ways joins, and normal usage starts to DoS it and nobody can accept that they get to re-architect or even at least fucking throttle requests, it's just "fix it", who knows how.

Bad workplaces definitely exist. Sometimes, they can be changed, and there's a ton of scope for you to be the person who came in and got a dysfunctional department functional; sometimes, they're broken at a higher level than you can fix, and you just need to leave.

But if you work at a bad workplace and your takeaway is "this industry is completely broken" and you turn into a full-bore cynic who refuses to believe that anything better is possible, you've gone badly astray.

I've left. I've left every time, and I've got a resume full of shit jobs I left after a year because they were shit, and I'm not sure what to do at this point to get the kind of position where this isn't how things are, where the sky is blue and up isn't down.

If there's part of the industry that's not like this, I haven't seen it and none of the people I've worked with have seen it, and I don't know it. At this point my wife has all but begged me to give up and settle for steady money with no purpose, my therapist is telling me to consider going back to school and pull a career change. I'm the only person I know in real life where there's any expectation that software makes sense and I question myself, wondering if pragmatic engineering in software is just a fantasy perpetuated by strangers on the internet.

Nah man. I've had the same experience until my current job and I think the only reason my teams been given the power to so things right is because the company went through 2-3 other teams that would take 6 months to take data from one of our services and put it in an excel sheet. Most of the places I have worked have had the engineers so far removed from anyone who had the power to actually allow changes to the process, that me and my coworkers didn't even know what they looked like. It seems like a matter of luck of being in the right place and right time, so that managers have had so many failures in software development that they are finally open to listening to alternatives

I'm in the same position. Plus with too many short term positions on your resume it makes finding a job at all (let alone a decent one) harder.

I have been at one place that was good though, unfortunately I left it to relocate. I haven't found anyway remotely close to the same quality in they ~6 years since.

I've developed a few proxy questions to estimate exactly how shit they are though.

Definitely have a refined set of interview questions developed, if nothing else to show for it. Never really get past:

"Walk me through the steps of the your design process, what steps does software go through to get from conception to production on your team, who is responsible for each step, and how do they test the assumptions inherent in their designs?"

"Uh... well... <handwaving about how roles aren't defined so nobody's responsible, why wouldn't you be confident about your 'decisions', maybe 'design' is too strong a word?>"

My best is "when I fix a bug, what are the steps to get it in production". It gives an insight into the corporate culture as well as their automation level.

Also, anywhere that uses TFS is an instant no, and I think SVN will be on that list now too.

Search for companies whose products you respect, and have quality design, and apply to them. Also, look for areas that require good quality - safety critical, high reliability systems for example.

It's not guaranteed, nothing is, but there are good working environments out there.

Agree. Truly bad software is going to be bad for the business. Software that grows more complex is rendered that much less adaptable to changing requirements, requiring more resources for its adaption. I accept that some employers and managers do not understand that reality, that maintenance can benefit adaptability and upfront work can create a better starting point that ultimately benefits the business as a whole by enabling more efficient execution.

However, there is also the danger of having an engineer who is mired in trying to achieve some (often incoherent or misguided) state of perfection, guided by a religious commitment to an unspecified measure of "best", paralyzed by the sheer number of ways something could be improved in some conceivable way. He risks living in a bubble, disconnected from the larger goal and reality the software he is working on is a part of. This disconnect results in bad prioritization and little grasp of trade-offs. The idea of "long-term planning" is also problematic because, taken too far, can become an exercise in speculation and fortune-telling. As Woody Allen said, if you want to make God laugh, tell him your plans. You can aim in a general direction, but expect course correction. There is no "once-and-for-all".

Effective engineering requires prudence. Mature and seasoned engineers are better able to distinguish actual needs from possible needs or wants, make decisions and prioritize work based on the limited resources they have. There are programming techniques and approaches (if not wholesale methodologies) that are motivated by this wisdom and that enable an engineer to manage the evolution of his software.

Between the extremes, there is a range of reasonable opinion and approaches. To me, it sounds like the author is either working in an exceptionally bad company or suffers from OCD.

I couldn't upvote this enough. Also, come on, it's not like everyone doesn't have bullshit in their workplace. I've never heard anyone except software engineers be so self-righteous and pretentious about our supposed special value in the business. Disdain and lack of empathy for working with other human beings comes a close second.

Edit, to add: This is by no means universal. I know and have enjoyed working with some very talented, humble, and empathetic engineers, too. I don't think most programmers have the attitude of the author of the article.

I tried very hard to take the perspective that this guy is irritated but that there might be some substance to his opinion. I couldn't help but constantly think this, though, "Wow, this guy is really mad, and now wants to logically apply blame to everyone and everything except himself and his choices."

Well commented, thanks.