Live data from Hacker News

Uncomfortable Truths in Software Engineering

buttondown.email

171–180 of 400 posts

Re: Uncomfortable Truths in Software Engineering

#171

My Own Addition: 14. Those who code for a living make good money. I have a lot of friends who went into various fields, and it seems relative to the number of buttons we press daily, anyone who works on software makes great money. We didn't spend a ton of $ to go to medical school and 3 years of residency. We didn't go to law school and take the bar. Most of us went to 4 years, or less, of school, and here we are mak…

I would gladly give up software development for a medical or law degree. I would gladly study for a bar exam or do a medical internship instead of grinding Leetcode and throwing salt over my shoulder or some other good luck inducing act, in the hope of passing the often subjective, 'are you a fit', can you design and code Z in the next 38 minutes type interview.

The barrier of entry is way too low these days and therefore we have this hazing ritual for an interview process. It's absurd to think that after 12 years in the business, I won't be able to figure out what to do with those requirements. I'm sorry, we need 5 years of Java, not 4.

For those young developers, save up your money over a 10 year period and get out.

Re: Uncomfortable Truths in Software Engineering

#172
post #83
post #73

Earlier quoted context omitted.

Typing is almost a no-loss addition though. If your function takes an integer argument and someone might pass it a string, that is a bug. It is quite hard to argue that a typing mechanism won't improve code quality, and it is very lopsided in the amount of time it takes to type a function vs. debug something that would have been caught by a type system. There are edge cases that can be argued all day, but if some lar…

What you’re describing is optional typing. What is usually derided as cumbersome is mandatory and exhaustive typing.

What if... we had the "best" parts of PHP or JavaScript development but for any traditionally statically-typed and precompiled language?

(sorry, I can't say that with a straight-face)

It could work though! And I don't just mean like Visual Studio's Edit-and-Continue feature...

Consider a language feature that lets you annotate a local/parameter/field's ("thing") type as "Hindley–Milner-esque" which tells the compiler to invert the thing's typing rules from prescriptive to descriptive (i.e. to mostly stop complaining and make the thing behave more like a JavaScript `object`, so the compiler only complains about 100% provably wrong usage of that thing).

Another "feature" of PHP/JS dev that I want to see in compiled projects is a way to run a project-with--build-errors by adding a toggle that instructs the compiler to stub-out all functions/members that contain build errors (even syntax errors!), this way we can do quick ad-hoc testing without needing the entire project to build. Think about the times when you your boss asks you to make 1 or 2 "minor" alterations for an unrelated feature and you don't think it's worth making a whole new git branch-andworktree for, but you can't test it right-away because of unrelated breaking changes you've already made.

Just some ideas...

---------------

Unrelated additional comment: I'm looking forward to when all programming languages fully support generalized ADTs. So many issues with data-modelling can be solved with ADTs and GADTs, but yet thanks to OOP's legacy from the 1990s we still have to shoehorn simple and clear models into inappropriate applications of inheritance. I want my intersection-types, damnit.

Re: Uncomfortable Truths in Software Engineering

#173
post #87

Earlier quoted context omitted.

You’re not wrong, but I’ll say the part about not going into it for the money is becoming less and less true all the time. For developers who are ~35 and up, almost 100% true, once you get younger than that you’ll find that there are a large and growing minority of people who are very much in it for the money alone without any particular interest or affinity for computing. Their parents, advisors, etc saw how much mo…

What I always tell people thinking about a software engineering career is that, yes, it's great money but I strongly advise only doing it if you actually like working with computers. Otherwise it's going to be a nightmare. Working as a software developer without a passion for coding is kind of like doing math homework every day for the rest of your life.

> doing math homework every day

Sigh... if only there were a way I could get paid for actually doing math homework every day...

Re: Uncomfortable Truths in Software Engineering

#174
post #10

Re. 3 & 5: my theory is that a language with gradual typing, gradual error handling enforcement, and "gradual proving" that is seamlessly embedded in it (see e.g. the https://nim-lang.org/docs/drnim.html experiment) could hopefully actually work here. And as to dynamic typing, I found it useful when prototyping, to quickly PoC/MVP the "happy path" of an idea/design, and see if it is worth investing any bigger effort,…

Gradual typing seems like the worst of all worlds. You spend time adding typing but can't depend on it consistently. I was surprised using Dart that it would throw runtime type exceptions even though it looked like the code had explicit types.

Re: Uncomfortable Truths in Software Engineering

#175

My Own Addition: 14. Those who code for a living make good money. I have a lot of friends who went into various fields, and it seems relative to the number of buttons we press daily, anyone who works on software makes great money. We didn't spend a ton of $ to go to medical school and 3 years of residency. We didn't go to law school and take the bar. Most of us went to 4 years, or less, of school, and here we are mak…

In the US* Canadian checking in :/

Re: Uncomfortable Truths in Software Engineering

#176
post #87

My Own Addition: 14. Those who code for a living make good money. I have a lot of friends who went into various fields, and it seems relative to the number of buttons we press daily, anyone who works on software makes great money. We didn't spend a ton of $ to go to medical school and 3 years of residency. We didn't go to law school and take the bar. Most of us went to 4 years, or less, of school, and here we are mak…

You’re not wrong, but I’ll say the part about not going into it for the money is becoming less and less true all the time. For developers who are ~35 and up, almost 100% true, once you get younger than that you’ll find that there are a large and growing minority of people who are very much in it for the money alone without any particular interest or affinity for computing. Their parents, advisors, etc saw how much mo…

And that's great. High wages means the market signals a shortage of workforce. That more people of lower productivity fill the gap means the market works in a healthy manner.

Re: Uncomfortable Truths in Software Engineering

#177

Earlier quoted context omitted.

What I always tell people thinking about a software engineering career is that, yes, it's great money but I strongly advise only doing it if you actually like working with computers. Otherwise it's going to be a nightmare. Working as a software developer without a passion for coding is kind of like doing math homework every day for the rest of your life.

> Working as a software developer without a passion for coding is kind of like doing math homework every day for the rest of your life. I disagree. I coded for fun once, as a kid, and have never felt the need to do it again. If I never coded again, I wouldn't even notice because I my passions lie elsewhere. But working as a software developer is still tolerable because I'm just sitting at a desk, typing on a computer…

Are you above 35?

Re: Uncomfortable Truths in Software Engineering

#178

Earlier quoted context omitted.

I'm honestly starting to feel like I transported back in time to my 1980's small town childhood, when the adults around me all blamed "Satan" for everything in the world they didn't like. "Capitalism" has about as much to do with software performance as actual devil worship had to do with my Dungeons & Dragons or heavy metal cassettes. And if your life as an engineer or user is "miserable" today, then I wish I could…

What sucks is having a supercomputer in your jeans' pocket that is significantly less responsive to your input than a Commodore 64 and is mostly used to deliver ads to you.

I realize that this will get some reflexive upvotes from the meme crowd. But neither of those statements are remotely true.

Re: Uncomfortable Truths in Software Engineering

#179
post #42

This one from the article is a bit weird: > Sophisticated DSLs with special syntax are probably a dead-end. Ruby and Scala both leaned hard into this and neither got it to catch on. Rails is one of the most popular web frameworks around and a combo of Rails and Ruby power some really high traffic / high importance platforms like GitHub, Shopify and Stripe's API.

I think he meant creating new DSLs for program code, not so much as a way to make libraries and frameworks more accessible. From my experience with Ruby, I really love well designed DSLs (like good APIs in general), but when people start to create their own mini-languages in existing codebases, you really have to call them back, because the quality of that code will be much harder to control (mostly because of the implementation via metaprogramming magic).
Post reply on HN