Live data from Hacker News

Uncomfortable Truths in Software Engineering

buttondown.email

281–290 of 400 posts

Re: Uncomfortable Truths in Software Engineering

#281

> Pairing is probably better than two solo devs if both pairers can handle it. Man, am I the only one that absolutely detests pair programming? Not only do I find it socially awkward, it completely kills my productivity. Software development is often about building a very complex model in your head and then figuring out the changes that need to be made. Having to dedicate half of my mental bandwidth to handling socia…

You're not the only one. I absolutely detest it (to the extent I would absolutely leave a job if they made it a requirement) and a significant portion of devs I have worked with are lukewarm at best.

Re: Uncomfortable Truths in Software Engineering

#282
post #168

Earlier quoted context omitted.

> And yet, their jobs are ESSENTIAL and we need people to do them even though they're grueling and underpaid. I think this touches on an uncomfortable point that many people don’t acknowledge: our current system generally* pays people according to how much they contribute to the economy and not by how much they contribute to society . The scalable nature of software means developers can disproportionately add value t…

I've felt for a long time that the reason software is not fulfilling its promise is because it has been tied exclusively to capitalist goals. The incentive structure is completely broken. I think a balance probably exists, but we are badly missing the mark.

Do you think that is still the case? I can think of all kinds of applications where software can contribute to non-profit driven goals. Healthcare, government, energy/climate, etc.

I think the problem is it becomes hard for some to take those jobs when they could instead work in, say, social media or finance for many multiples of the pay.

Re: Uncomfortable Truths in Software Engineering

#283
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,…

> Question is, can anyone design & implement a language that would have all of that, and still be readable and understandable to a common programmer No, because exception handling and the answer to "what type are these data?" are product questions. Hard questions that no one really wants to work out because what if our customer base wants something completely different in 6 months? This is largely reflected in cloud…

Hm; I guess when being in talks with a company using the language, assuming the pragmas idea I elaborated in a cousin comment, I'd then be asking questions like: "Is your codebase any=default or any=forbidden? What percentage of it is any=allowed?" (Instead of the current: "are you using JS, Go, or Rust?")

Notably, in my particular case, what you say is a problem is exactly why I want it: because when writing the PoC, I don't really know what I'm doing yet; and I want to only sketch it. Once I see the sketch and it looks like the general idea has some promise, I want to "grab the pen and start drawing" - i.e. start diving into the nitty-gritty dark corners of ugly interactions, corner cases, & stability, as a way of better understanding & exploring my domain/project/idea (specifically, using the compiler as a tool that is forcing me to do that, by asking me difficult questions). And I may want it graded in various areas of my codebase: some are super unimportant or still being explored, and I'm ok having them explicitly marked as "sketchy"; others are where I really care about extreme security, so want full prover power, and I want to know their exact boundaries too; finally, some are the "more or less know what I'm doing, but not life-critical" to bigger or lesser extent; notably with some small corners marked with an explicit "caution: here be dragons" `unsafe` (I mean, `any=allowed`) yellow tape.

Re: Uncomfortable Truths in Software Engineering

#284
post #261

Earlier quoted context omitted.

Yup. I even planned out my debt at the age of 17. When I selected a college in 2005, I would have graduated with 8k in debt. Quite reasonable. The crash my junior year and the resulting divorce of two of my parents means over half my undergrad debt was from my senior year. I had to choose between doubling my debt and dropping out with a year left. And I also effed myself by working my way through school to try to kee…

I had a very similar path to you. I felt like I had been responsible and made it all the way through college. Then I had $75k in debt and I was going into $8/hour interviews with 40-60 other applicants. One time I stopped at kinkos to print out some portfolio designs for an interview, and the cost was 6 dollars. I had to leave because I only had 3 dollars. Things are much, much better now that I transitioned into tec…

I'm actually in political communications; I leaned heavily into the rise of identity politics. (I'm a gay disabled female. Not great in early 00s tech, especially as a teenaged girl, but VERY good in certain spaces). I do tech stuff for non-techies, and it works pretty well, especially as there's more crossover between politics and tech. (I had to explain rms to a bunch of policy wonks the other day, that was weird).

I just missed talking about tech and was sick of getting blank looks when I rambled about how Page Rank is a mistake.

Oh, and regarding HN, I've been here on and off lurking since it was founded in 2005, I just thought I was too stupid to contribute. Now I'm old, jaded, and realize we're all stupid.

Re: Uncomfortable Truths in Software Engineering

#285
post #13

Earlier quoted context omitted.

Software is not charity. I will not work hard to deliver all those things out of the goodness of my heart. The ROI on those things isn’t great. If it’s easy to do I’ll do it, but none of those are trivial things.

It is unfortunate that parent latched on to capitalism. Point number 13 from the post resonated with me the most since the software I write can damage the environment or expensive machines that are difficult to replace if there are errors, and as a professional electrical engineer I do sign off that it is built correctly and am liable, and therefore I limit the scope so I can manage the workload, document test result…

>"Imagine if you could sue software vendors for lost revenue due to bugs"

It does happen when software is made under specific contract. You do pay an exorbitant price for such software though.

For generic software - this is the dumbest idea I've ever heard. Go sue your politicians instead. I am pretty sure you'd find enough cases of lost revenue / income coming as the results of their actions.

Re: Uncomfortable Truths in Software Engineering

#286

Earlier quoted context omitted.

Are you sure the current campaigns aren't effective? The demographics are indeed changing. I know causation correlation blah blah, but we're just speculating in this thread, supplying no data anyway.

> The demographics are indeed changing. The gender ratio isn't changing though. If anything it is becoming worse, it was decades ago that less women went into software engineering today. The only thin that changed is that now every company tries to put their women software engineers front and center, in their marketing material, to go speak at conferences etc. So it looks like there are more women, but there aren't.…

This page suggests otherwise (although the effect is slight): https://www.zippia.com/software-engineer-jobs/demographics/ Do you have other data?

Re: Uncomfortable Truths in Software Engineering

#287
post #214

Earlier quoted context omitted.

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 ther…

I know people saving up and getting out of the medical field, as it became extremely toxic in the US. Expensive and mostly ran by huge corporate entities seeking profit. I would much rather click on a computer.

In the end, everything you do for money will become "work", because if it was only the fun parts people would just do it for free as a hobby (see also: open source).

Re: Uncomfortable Truths in Software Engineering

#288
post #258

Earlier quoted context omitted.

The issue is the same in reverse. I've heard horrible anecdotes by male friends in female dominated industries such as teaching, nursing, etc. Why is the same societal push not happening in those industries? I never said we shouldn't strive to be welcoming and to cultivate a friendly environment for all, just that the intentional push for more of any specific demographic seems strange to me. Shitty people are going t…

While there may not be similar pushes in other industries, there is no reason to dismiss the efforts to encourage participation in software based on a lack of effort in other fields. Implicit and explicit biases exist everywhere. My wife is in teaching, and would love to move into administration some day. The problem with that? Despite women being the dominant sex in the actual teaching position, men continue to fill…

My point is that societally we should allow anyone to enter any field they desire with minimal barriers halting their progress so long as they are able to do the work - but we shouldn't try to force it just because we feel like there should be more women or more of whomever. Just because there is a disparity in the demographic make-up of a field doesn't automatically mean that's it's root cause is some negative bias or discrimination. Maybe more men fill administrative roles because more men pursue educations in business administration and leadership whereas a teacher can be an excellent educator, but a not so excellent administrator if they have no relevant experience. Does your wife have any experience in administration or any credentials that would show her to be qualified for the job? If not, maybe that's her issue - not sexism. That's like asking why do great software engineers sometimes never rise to staff/management positions - because they're good at writing software, not managing people and organizations. Is this bad? Why? Because administrative roles are generally better paid and more prestigious and more women should have that opportunity? Why not encourage more women to get into masonry or welding? Where's that movement? Has it maybe not happened because those aren't well-paying, desirable jobs for most people? Do more men occupy those industries because of the nature of the work or because of some insidious rampant sexism? I'd be inclined to say the former. If this were actually about equality, it would be happening all across the labor market and not just in a certain subset of high-paying fields.

Some of these disparities can be traced back to social conditioning and discrimination, but its also in large part just due to inherit differences in the interest and abilities between genders. It's been proven time and time again that the genders are often fundamentally different in terms of abilities and innate interest. Neither gender is better than the other, but we are different and denying that does more harm than good.

Re: Uncomfortable Truths in Software Engineering

#289
post #33
post #17

Earlier quoted context omitted.

Capitalism is a handful of people who own the means of production and the rest of us trying to get by. The bad apples exploiting it are the people who own the means of production, and saying they're the bad part of capitalism might as well be saying "capitalism is only bad because of what makes capitalism what it is".

> Capitalism is a handful of people who own the means of production and the rest of us trying to get by. Well, good thing then that the "means of production" for software development consist of a 500€ laptop, which is well within reach of just about every programmer in the Western world.

[deleted]
Post reply on HN