Hacker News Reader

Oh my goodness, no -- that wasn't it at all. To the contrary, the 1990s sucked for software development: everything was proprietary and (not unrelated) mostly terrible. Worse, the world was moving in the wrong direction, as what had started as a liberating computing movement (personal computing) had turned into a proprietary monster in the form of Microsoft. If you want to know what software development in the 1990s was like, read "Showstopper!"[0]; if you want to know what it was like to try start a company in the shadow of Microsoft, read "Startup"[1] -- and if you want to know just how shabbily software engineers were thought of, read (actually don't -- it's terrible) Ed Yourdon's "Decline and Fall of the American Progammer."[2]

Anyone telling you that the 1990s were "all about the craft" is pranking you. This may be an uncomfortable truth, but you live in the best time in human history to be a software engineer!

[0] https://www.goodreads.com/book/show/1416925.Show_Stopper_

[1] https://www.goodreads.com/book/show/1171250.Startup

[2] https://www.goodreads.com/book/show/250164.Decline_Fall_of_t... -- but NOT recommended!

> "...as what had started as a liberating computing movement (personal computing) had turned into a proprietary monster in the form of Microsoft."

Given that most of us today work in server-based software, it must be mentioned that the UNIX server/workstation vendors were equally interested in becoming proprietary monsters of their own, with Sun Microsystems at the top of the heap and charging prices that made even Microsoft server products look attractive. They would've been a Microsoft if they could've and they certainly tried their damndest to do so.

I am 50 years old and I agree. I've never liked programming as much as today, because I do less of it and get to collaborate with all the other people also doing less of it. Basically, programming is a terribly difficult way to spend time, and open source let's us reduce this tax on humanity.

Also, having to ship the product on physical media and fast internet not being a thing meant that software would actually have a "finished" state. Today nothing is ever finished, everything is in eternal beta and constantly updated for no good reason.

I was a professional developer starting about 1996, so this doesn't apply to earlier timeframes, but there were a lot of people TALKING about software engineering be a craft. In the trenches, there were a lot of people just trying to get things working. You would try to do this "the right way" (cf. how Agile is described vs how it actually works today) but a lot of it was aspirational. We were hacking things together and rushing it out the door back then as well.

On the contrary most programming history stories I read talk about how one had to come up with a clever solution or shortcut to hit a deadline…

I hear this too, but don't forget about context. Like the article states, it was hard to push updates, so there was a grind. Extreme Programming wasn't a thing yet, nor was online updates to software, so there were self inflicted downsides.

It's also not like everyone forgot at the end of the day there was a business that had to be run, and profits had to be made, to continue working in the craft.

And yet, even these "hacks" were interesting, at least, and to some extent, sometimes quite masterful.

When I listen to folks re-calling this period its not that they don't say there weren't short comings, of course there was! Its that they remember everyone being in it together, in the thick, and really collaborating, because they cared, even when they had to take shortcuts to meet a deadline.

Maybe that's what it is, the average engineer just doesn't care anymore like that, for better or worse. Its a hard thing to describe exactly, but it sure isn't prevalent now.

And who can blame the average engineer today? Business incentives are often actively hostile to caring in this fashion. Technical excellence is not a goal anymore. Worked at many places now, and IME all have the same broad stroke issues around quality, meeting deadlines, product owning engineering work pipelines (definitely not true Agile, where teams are autonomous) etc.

I disagree with you. It's still "about the craft" for probably just as many people as it was back then... But of course now there are way more people and it's much simpler to enter the field. Now, you don't need a college degree to get a job in this business. However, just as many people as back then still do get that.

> I want to work somewhere again that sees engineering software as a craft again.

If you find this place, will you tell me? I will come work with you.

I admit though, that I struggle to codify what “coding as a craft” is. And that worries me. I fear I am really just playing a game of “I’ll describe it when I understand it” up-over-that-next-hill-ism with myself that is illusory and delusional.

Closest I ever got was working at Apple, and even then it was due to the fact I was on a very specific type of team, so I don't know if it was common case or not.

I hear Google is largely like this, but who knows anymore. I hear mixed things all the time. It feels like you have to find a specialized company that may be immune to certain pressures and likely top of their field or the only company really in their given market sector. Maybe Oxide Computer?

I think Supabase might be like this, given their marketing and hiring materials, but its hard to say. They're in a "long game" (according to their founder) so they think more long term. That tends to be a good indicator of this, I think, is seeing long term horizons over quarterly ones.

Google used to be like this, but now, though some isolated pockets remain, is not like that anymore. A good mental model of how Google internally works today is Microsoft, but with free food.

My time at Microsoft was learning a craft from old guys who were there in "the beginning". I'm so grateful for the hours spent on a whiteboard with a patient sage explaining to me how things work. My code reviews were 10 iterations until I learned to do a better job. Very high bar. Even comments had to be full English sentences. I miss it.

AWS is the opposite.

Not sure I agree with your experience at AWS. For me, my teammates have been super critical, always trying to raise the bar and looking for ways to make things better. So, all I’ll say is that it is very team specific and you can find good and bad teams at every company.

{supabase founder}

We're fortunate to have started at a time when VCs were incredibly irrational (read: good for founders), and even more fortunate to have found a lead investor that's patient.

We've been able to build Supabase our own way: hire the right people (mostly international), focus on what developers want (even though they don't pay much), and build open source (collaborating rather than competing). None of these are controversial until you have a profit-maximising VC breathing down your neck.

> They're in a "long game" (according to their founder)

I stand by this. It's a decade-long endeavour to build credibility as a database company and that's not something we can hurry.

Perhaps we should talk :)

> I struggle to codify what “coding as a craft” is

It means working with people who care about the quality of their work.

Does caring about the quality actually mean the quality is good? Maybe it doesn’t even matter. If the team cares and they are satisfied with what the quality of what they are building, maybe that’s enough?

Yes, that’s enough for me. Intent is everything to me. You’re free to have a different opinion :)

>I struggle to codify what “coding as a craft” is.

It means different things for different people, but for me, it means:

  Step one is getting it to work, step two is making is as simple/clean as possible (most people stop at step 1 it seems).

  Take time to fix issues / sloppy code when you see it.

  Ideally you want the codebase to look like it was all written by one person.

  Carefully balance maintainability vs speed or cleverness.

  Refactoring is a necessity and should be done periodically. Same with tuning.

  Take the time to name your methods/classes/variables as accurately, verbosely and consistently as possible. 

  Test your shit for bugs before you give it to QA, for the love of everything holy. If QA sends something back, you should feel a little embarrassed.

  Take the time to write useful comments. Focus on intent, that way the next person can know if the code is doing what it's supposed to or not.

  KISS, DRY, YAGNI.

The best test is when I come back to my own code I wrote 6 months ago and if I say, "who the hell wrote this shit?!" and it's me, I need to clean it up.

What's the quote about writing a shit program and then thinking you're clever when you fix SOME of the bugs it has?

I 100% agree with all of that. That’s how you make good software in a sustainable business.

Unfortunately, that’s not how the market works anymore.

Do the minimum, get to market first, hype features over reliability and performance, get a nice looking balance sheet, and cash the fuck out.

I love writing software, but I hate this industry.

You wrote: <<The best test is when I come back to my own code I wrote 6 months ago and if I say, "who the hell wrote this shit?!" and it's me, I need to clean it up.>>

Up vote on this! I do it once a week -- at least. First, I am frustrated by some unreadable logic, then I look at Git blame... "Oh..." Second, fix it... again!

> codify what “coding as a craft” is

It means you produce something that works, has some consistency of organization, and most importantly: other developers will be able to come behind you to support and extend it.

> ...I think we as an industry have let this go, especially since the rise of bootcamps. It just isn't about the craft anymore, its all about "hustle". There is some truth to the fact that engineering in this time there was more caring about it as a craft, caring about performance, caring about shipping quality etc.

Hustle almost always seems like the most direct path to market/economic success. As market imperatives increasingly dominate, other priorities (like "craftsmanship") fall by the wayside.

IMHO, the market system is important and useful, but it's also pernicious in a lot of ways. It needs to be powerfully kept in check, otherwise things become shiny and hollow.

Its a bubble / bust mentality though. I remember a lot of people pivoting from finance (the previous "winner" of high salary, high growth opportunities pre mortgage crash especially) to tech, that also corresponded with the rise of this culture, IMO. Still was happening until maybe very very recently, MBA's were flooding the tech sector looking for opportunities, founding companies etc.

Unsurprisingly, this is when "hustle culture" and the explosion of management roles started to take off in earnest.

Craftsmanship isn't a bubble / bust mentality. Good work should stand the test of time, as it were.

>I want to work somewhere again that sees engineering software as a craft again.

I see this as an economic question. Few software products are going to have any real longevity, and few companies are willing to pay for high quality engineering. This isn't to say that the people working on the products aren't good engineers or that the products are garbage, so much as to say "good enough" is good enough for most products and companies.

I appreciate the craft type of working! Within a craft you care about your work and your tools.

The German phrase "Beruf kommt von Berufung" describes the howl attitude but all translations to English seem improper. Because it is a pun and probably because the apprenticeship (vocational education at work and school) isn't such important in the English speaking world.