Tux Machines
Posted by Roy Schestowitz on Mar 26, 2023
=> Gemini Articles of Interest | today's howtos
=> ↺ I’ve been employed in tech for years, but I’ve almost never worked
When Twitter fired half of its employees in 2022, and most tech giants followed suit, I wasn’t surprised. In fact, I think little will change for those companies. After being employed in the tech sector for years, I have come to the conclusion that most people in tech don’t work. I don’t mean we don’t work hard; I mean we almost don’t work at all. Nada. Zilch. And when we do get to do some work, it often brings low added value to the company and its customers. All of this while being paid an amount of money some people wouldn’t even dream of.
What is happening right now in tech may be one of the greatest market inefficiencies—or even deceptions—in history. I am writing this article because I think outsiders deserve to know what’s really going on in the field.
=> ↺ Project Management for Software Engineers
At some point in your career you will be asked to manage a project. This can be intimidating, it can be scary, but it doesn’t have to be. We can leverage some time-honoured techniques, and adapt them to the unique approach required for software projects to deliver on time, on budget, and with success.
This article is a collection of techniques I’ve learned for managing projects over time, that attempts to combine agile best practices with project management best practices. If you study project management to any level of depth, it is inevitable that you will come across the Project Management Institute, or PMI. The PMI is a global professional body that provides training and certification in project management topics. PMI provides different certification options, including some for Agile processes and Scrum.
Technical debt is an often debated topic. Like most concepts in software, it isn’t particularly difficult to find arguments supporting opposite sides of the spectrum - in a single minute of searching I was able to find that some believe that technical debt doesn’t exist, while others feel that technical debt is the most important aspect of product development. From the conversations that I’ve had with others in the industry, both within my place of work and with technical leaders from other companies, I’ve come to believe that one of the root causes of the gap between these viewpoints is primarily definitional.
Part of the reason that some people don’t like the term “technical debt” is that they feel it becomes an excuse. To these individuals, everything that software engineers don’t like within the system on which they’re working gets labeled as debt, and that debt becomes a boogeyman that gets blamed for all of their problems. Those on the other side of the argument feel almost the exact opposite: technical debt gets little attention and they’re forced to spend inordinate amounts of time struggling against implementations and concepts that make it more difficult to make changes than it otherwise could be. An interesting realization (and something that makes this conversation particularly difficult) is that both groups can be right at the same time. This can be true only because the two groups are misunderstanding one another. But where does this misunderstanding come from?
=> ↺ Why people misuse inheritance
In the thread, he recalls the adage "prefer composition over inheritance". This is a well-known principle of good OOP code, and yet inheritance is commonly used where composition would serve better; the question that comes to my mind is, "Why?" I think I have at least a partial answer, but let me meander a bit before getting to it.
The thread gives an example use case of a map that counts explicit insertions, which is the example I'll use here. If you inherit and override the put() method, the behavior you get may be wrong, or may be right in one version and wrong in the next. On the other hand, you didn't have to write a lot of code.
(One post, an oldie but a goodie, that significantly influenced my thinking on this matter, suggests that you should never override a method that was not designed to be overridden, and talks about how building this into the language slightly improves ergonomics when you do override.)
Suppose I did the "right" thing and used composition (in this case, also delegation, and also the decorator pattern, for people who think in GoF design patterns). I would have to implement the map interface, calling down to a map implementation that stores the actual data. To implement the Map interface in Java I would need to implement 25 methods! Most of them would be boilerplate, just passing the arguments to the equivalent method on the delegate. Other languages are not better (the Haskell Data.Map module has more than 100 functions).
=> ↺ How Big Should a Programming Language Be?
Reading the thought-provoking "Patterns & Abstractions" post reminded me of a long-held opinion I have about programming language design: we have a tendency to keep adding features to a language until it becomes so big [1] that its sheer size makes it difficult to use reliably. Since most of us spend most of our time programming in one language, it can be difficult to see a common trend amongst languages in general.
=> gemini.tuxmachines.org This content has been proxied by September (ba2dc).Proxy Information
text/gemini;lang=en-GB