> 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…
Uncomfortable Truths in Software Engineering
331–340 of 400 posts
Re: Uncomfortable Truths in Software Engineering
#332My 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…
Wait until you get to your 40s to appreciate other factors. "teachers, firefighters" enjoy: * structured careers with well-defined benefits that they keep even after retirement * accumulate experience that's valued by their employers all the way to retirement * can find a job anywhere; don't need to emigrate/move to SFBA/NYC/London/Berlin, speak foreign languages, be surrounded by aliens from distant lands * are resp…
If you get to your 40s as a dev and want that without leaving development, become a public sector (direct government, not contract) software developer.
Re: Uncomfortable Truths in Software Engineering
#333Earlier quoted context omitted.
(Rereading, I'm not actually sure we disagree, but the tone of the parent post seems to be that I can't change things because people won't change, ...?) I'm in tech, I work on fixing tech. > the intentional push for more of any specific demographic seems strange to me I believe the skewed demographics is a reflection of actions and pressures I don't agree with. I think there is pretty-open discrimination and steering…
I'm unsure what you're trying to express in this reply. It seems we do agree in general viewpoint, just perhaps we have different ways of expressing that view. Discrimination definitely happens, but I have yet to see one example of "pretty open discrimination" that hasn't resulted in an all out PR disaster for the org involved ,your "Read the news" statement supports that. If discrimination were a common occurrence i…
Re: Uncomfortable Truths in Software Engineering
#334Earlier quoted context omitted.
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.
So, that makes me notice I didn't clearly explain, that my idea here would be for some kind of guard blocks that enforce static typing (etc.) in some areas of code. Kinda similar to "unsafe" in Rust: ideally, you could start with e.g. fully dynamically typed code, then mark some parts of it with "I want this area typechecked", finally requiring all of it to be. Now that I think of it, seeing that in statically typed…
ETA: If you're suggesting actually preventing the flow of Any-typed data out of the Any-typed blocks, well, that's going to make things pretty hard. Any-typed code wouldn't be able to call any "safe" code, because that safe code might do something like take its (presumably safe!) input and stash it away somewhere. Safe code wouldn't be able to access any unsafe data whatsoever - all calls into unsafe code would have to be completely procedural. It'd be painfully limiting.
I'll also add that it's not trivial at all to statically type a dynamically typed code base if it's exploiting that dynamism at all. "Just go back and add type annotations" could be a multi-engineer-year project requiring refactoring of huge chunks of the system. If you believe in static types, encouraging completely unprincipled dynamism at the language level for any reason besides backwards compatibility with existing dynamic code seems like a mistake.
Re: Uncomfortable Truths in Software Engineering
#335Earlier quoted context omitted.
You're correct about my language choice, I could (and should) have used more neutral language to describe my position. While I do believe that there are some fundamental differences in the interests and abilities of the genders (neither for better nor worse, they just are) I also agree that's its a slippery slope that has been abused in the past. Societal pressures and conditioning certainly play a role, however I th…
I disagree about the “equally important” stuff, and here’s why: If I’m wrong and the overwhelming majority of women really don’t like programming, I’ll have wasted some of my time, but no one will have been materially harmed[0]. However, if I am right, then there are currently a large number of people who are being pushed away from a career or hobby that could increase their overall happiness and/or standard of livin…
Anything more and it becomes the individual(s) behind the movement projecting their desires onto others and is no different that the societal molding that's taken place for the past several decades.
Re: Uncomfortable Truths in Software Engineering
#336Earlier quoted context omitted.
Agreed. I spend a lot of time on TikTok (my main interests tech-wise are HCI, digital discovery, and social computing so it's like catnip) and a LOT of younger people are going into tech for the money. I'm 33 and I started programming in the 90s (I was raised by two geek parents a la Larry Page who were supportive), so I'm sort of in-between the two 'generations'. At age 37 and above, pretty much everybody is either…
What you're seeing is really the same pattern as the late 90's dotcom boom-bust. Then, too, TONS of people (and their sisters and mothers) went into the "Information Superhighway" to become "WebMasters" and develop "Web Sites" for businesses large and small as more and more money plowed into those companies and a rush for talent, including not-very-much talent was drawn into the field because of the $. When the dotco…
FAANG and dev positions in general, though, I think people are treating like they used to treat being a doctor/lawyer/accountant: It's a good, steady living and it will always be around. That's very different from the dot-com boom, which was way more a gold rush, even at the entry level. ("They're willing to pay HOW MUCH for the stuff I was playing around with?") Somebody who started at Google in 1999 (or Amazon, or even FB in 2006) is very different than most people entering those companies now. The dotcom was high risk high reward like modern web3/crypto, whereas modern swe positions are low risk medium high reward, which makes them great for people who are more risk averse for whatever reason.
Re: Uncomfortable Truths in Software Engineering
#337Earlier quoted context omitted.
I wonder if it was the case in the previous decades. I assume that a lot of this comes from the fact that computing is now more than trendy, and being knowledgeable on it makes you feel like king of the hill. Also lots of people going into computing, knowing the recent history. Strong opinions about things based on the last 10-20 years, choosing their little church. While having next to zero knowledge about previous…
> I wonder if it was the case in the previous decades. Less so, in my memory. Sure there was hubris. Sure there was conflict. But there was also a recognition that we were all small fish in a big pond. And there were still people around from when computing was an even smaller sliver of the economy, who tended me more "grounded" than anyone you'll see today. Now that computing companies are among the richest in the wo…
- innate difficulty: it's a bit harder to make an application on a 286 machine, you need to think more, you can't clone a template and tweak a few things to get a fully featured platform
- also, more utility driven, can't make shiny visual and presentation. the app has steps toward goals and you get done quicker.
Re: Uncomfortable Truths in Software Engineering
#338Earlier 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…
It feels to me like most people no longer find fulfillment in their work, regardless what it is. It really seems like almost everyone is in it for the money and could care less about the lack of craftsmanship.
Re: Uncomfortable Truths in Software Engineering
#339Earlier quoted context omitted.
You're correct about my language choice, I could (and should) have used more neutral language to describe my position. While I do believe that there are some fundamental differences in the interests and abilities of the genders (neither for better nor worse, they just are) I also agree that's its a slippery slope that has been abused in the past. Societal pressures and conditioning certainly play a role, however I th…
I disagree about the “equally important” stuff, and here’s why: If I’m wrong and the overwhelming majority of women really don’t like programming, I’ll have wasted some of my time, but no one will have been materially harmed[0]. However, if I am right, then there are currently a large number of people who are being pushed away from a career or hobby that could increase their overall happiness and/or standard of livin…
Re: Uncomfortable Truths in Software Engineering
#340Earlier quoted context omitted.
Number one, static type checking is hardly a "new tech" for which the industry is in a "newlywed period". If anything, it is the middle-aged wife that the industry's crawling back to, as the passion fades from its dynamic mistress dalliance. Secondly, the obvious counterexample here is MongoDB. Way too hyped-up during its honeymoon, and then almost immediately crapped on by the entire industry (to the point where we'…
Also, TODAY type checking (and more important, how Types are used) is not the same than YESTERDAY types usage. Java, C++ and similar are terrible benchmark for it. Before, types were almost for do taxonomy, with limited help to actually write CORRECT code, and more important, MODELING the domain was very verbose and with limited advantages!. Against that , no static types makes more sense. With o without the end resu…
This is why hybrid typing is so prevalent nowadays, as you don’t need to satisfy any internal need of the compiler, but you can still keep the documentation of models and interfaces that static typing gives, where desired. Performance is usually also a no-factor nowadays unless you have high demands.
On top of this, the only reason JavaScript grew so large was that there was literally no other way to ship code to a user. IE6 was the universe. Nobody wrote code like this by choice. And those unfortunate souls that did still have scars from it. Remember this was also before CI checking every PR for correctness became as common as it is today.
Because of all this, there will not be any “swing of the pendulum” back to the crazy era of untyped PHP, JavaScript without TS or python without mypy. This is something that is here to stay.