What do all these things have in common? MS Visual Basic 6, MS ActiveX, MS Silverlight, MS Visual Foxpro, MS C# .NET Compact Framework, MS ASP.NET WebForms, MS ASP.NET MVC, MS Windows Communication Foundation... I think there common is a theme there. But shhh, don't tell him.
My 20 year career is technical debt or deprecated
321–330 of 585 posts
Re: My 20 year career is technical debt or deprecated
#322Earlier quoted context omitted.
That's the usual path of becoming conservative as you grow up. Or phrased another way, becoming normal. The training process humans go through leads to a lot of weird biases, just like how RLHF contributes to models getting bad ideas as well as good. For example, you spend years in school being instructed as efficiently as possible in the one right way to do things that was already discovered. You are only rarely or…
Not sure why you are downvoted, this is one of the best comments I've read in a long time. How idealism turns into realism and the sweet spot is probably somewhere in the middle.
For example, most companies with large software assets will at some point go through a fight between the old hands and younger devs about whether to do a rewrite in the hot new thing. Which side you're on may appear dominated by age, but it's really more about your intuition about the risks of rewrite projects. That in turn is determined by your experiences of people's ability/inability to fully comprehend complex systems.
Also I didn't try to to be neutral, hence the digs at communism and academia. If I was aiming for karma I'd have left those out. But I'm not.
Re: My 20 year career is technical debt or deprecated
#323> All code rots or gets replaced > Over time, you can see how almost everything you create gets scrapped and replaced for various reasons or is now based on old technology. Is this problem fixable by using some great technologies? React code does not rot and Common Lisp applications are famous as having the most time without getting rot among other programming languages.
React code does not rot? How so?
Re: My 20 year career is technical debt or deprecated
#324I feel like this is heavily connected with the idea of legacy. I grew up in Scotland, and lots of the buildings, culture, etc, have been around for hundreds of years. It would be nice to feel like something I was building would last as long and outlive me. It doesn’t though. Sometimes I think that this is just the nature of software development. Most of the stuff I build is built to solve an immediate business proble…
Why though? Does it really matter if something outlives you by 200 years? 500? On a not-that-long timeline like 10,000 years, nothing lasts. The "cathedral-like" timeline is completely arbitrary I think. Imho, there’s freedom in accepting that nothing I produce will last a long time.
For somewhat related context: all my life until recently I rented, but now had become a house owner. My strategy with things I bought for daily use was that they were meant to survive until the next move. For many things it wasn't economical to take them with me to the new place. So, for example, I didn't want to buy a "proper" pan / skillet, and was happy with a teflon one just because it would wear off about the time I needed to move again. I could just throw it away and get a new one. Now that I don't intend to move, I'd choose to buy things that last, because cost of moving vs cost of garbage cleanup changed.
Now, when it comes to software, it looks like the industry is overwhelmingly motivated by short-term benefits, where, in principle, it shouldn't have been. And this is the surprising part. Lack of vision / organization leads to the situation where we never even try to make things that last. There are millions of e-commerce Web sites in the world, but they are all trash because nobody could spend enough time and effort to make one that was good (so that others could replicate / build on top of it, and also have a good product). We have the most popular OS, that's absolute garbage, both the core and the utilities around it, which is due to shortsightedness and even unwillingness to plan on the part of the developers. Same thing with programming languages, frameworks etc.
So, looping back to your question: why the magnitude matters? -- what matters is how your own planning compares to the lifespan of your product. Many times in my career I was in the situation where I was building an already broken thing from a design that was known to be broken from the start or very soon afterwards. And that had nothing to do with changing requirements, it had all to do with the rat race of getting a product to the market before someone else does / investor's money dries out. The idea behind "things that last" is that at least at the time you are making them you cannot see how whatever you are making can be done better (as in more reliable / long-lasting).
In the end of the day, what happens now in programming is that things that shouldn't outlive their projected deadlines do, or, predictably, die very fast. But we don't have any section in the industry that builds things to last. We just keep stuffing the attic with worn-out teflon pans.
Compare this to, for example, painters, who despite knowing that most of their work will likely be lost and forgotten, still aspire to produce "immortal" works of art, and if a picture takes a lifespan or more to make, then so be it. (In the past, some works of art were carried out by generations of artists, especially, when it comes to books where scribes were succeeded by their children who'd continue writing the book after their parents death).
Re: My 20 year career is technical debt or deprecated
#325That's like calling a chair you built 10 years ago "technical debt" because it can eventually break. No, it's just a fucking product you made. The fact it has to be maintained doesn't mean it is "debt", it's just like any other asset. You don't get to your car and think "that's technical debt". There is nothing technical about it. It's a tool with maintenance needs. The difference is choosing worse now to get it fast…
The author navigates the technology world very differently than I do.
Re: My 20 year career is technical debt or deprecated
#326Earlier quoted context omitted.
But is WSL1 supported by the POSIX layer? I don't think so. I think it uses some of the mechanisms built for the POSIX layer but I think it is a separate "personality".
See my post to a peer; this comes from the DEC Mica project, the cancelation of which directly led to Windows NT. Windows was designed in part as a UNIX kernel.
Re: My 20 year career is technical debt or deprecated
#327I am somewhat amazed at the list of tech from that article, it's like he has a magical knack for picking dead ends. C was the 2nd language I learned and I'm still using it. The big surprise for me has been javascript - it's so...bad it became good or at least ubiquitous.
I just ended a job with a guy who going on about how he was a Flash hotshot back in Y2K days, lamenting "Steve Jobs for killing it." Like, dude, everyone with two neurons to rub together told you it was a fundamentally terrible idea, doomed from the start. Gawd.
I also fell for a few of his picks — Angular was a rough blow — but what a list of lousy bets.
Re: My 20 year career is technical debt or deprecated
#328Re: My 20 year career is technical debt or deprecated
#329Earlier quoted context omitted.
Does anybody know where I can find a good, substantiated, critique of the common Java coding patterns, including on Android? This niche is such a huge mess that simply documenting all the bad things in a single codebase (along with explanation why they're bad) took me a month. It's tiring and mentally draining to do this: every other line of code you read makes you go "Why. Please, just tell me why anybody could ever…
Hah. I’ve spent several years writing javascript for a living. You can always tell when code was written by someone who’s arrived fresh from Java or C++. Their code is full of hundreds of lines of useless classes which can often be replaced by a few simple object literals. Unlike class instances, object literals can be easily json stringified and parsed, too! You can torture people who are like this in code review: “…
Lol true
Don't forget all the getters and setters merely updating/reading a variable
Python says "explicit is better than implicit" but Java goes too far with it, and in the most verbose/inflexible ways possible
Re: My 20 year career is technical debt or deprecated
#330Earlier quoted context omitted.
It's comforting to think that 2000 years from now, all that may remain of the early web and modern culture is the Space Jam website. Maybe Space Jam the movie will be looked at as our Gilgamesh or Iliad.
And the Galaxy Quest site -- will people in the future know it is a parody? http://www.questarian.com/