A couple of months ago, developers on Twitter started spamming jokes or frustrations about the mythical “10X engineer” in response to this tweet by a startup investor from India. Thankfully, outside of this guy’s original tweet thread, nobody else was buying the “10X engineer” nonsense. Unfortunately, the fact that this guy tweeted it in the first place means there’s too many people out there laboring under a delusion that desperately need to be set straight.
I’ve been developing in Java since late 2009. It’s a good language, but I’m starting to wonder what kind of future it has. I’ve been using Java 8 since shortly after it came out, even though Java is currently on version 11. Java’s obviously still being developed, so why not move forward? A big part isn’t the infamous module system that launched in Java 9, and broke a lot of stuff. Part of it is the fact that Java is owned and controlled a by a company that seems more interested in rent-seeking off oa Java than doing anything innovative with it.
Software is written to solve a problem. Sometimes, it’s more than one problem, but you get the idea. Being someone who both uses and writes software, I’ve found the best software out there doesn’t just solve a problem, but was written with a clear and definitive opinion about how that problem should be solved. That’s not by accident or coincidence, it’s very much causal.
I got a comment on my post about performance tuning a REST API call asking about code tuning with examples. I don’t have code examples handy, but I can certainly run through some general performance tuning tips I’ve found over the years. No matter where you find advice about improving your code’s performance, keep in mind that every situation is different, and those differences could impact the relevance and usefulness of any advice offered.
Probably 1 of the most difficult juggling acts in software development is scoping a minimum viable product. I’m pretty sure a lot of that comes from the juggling act and judgement calls that constitute defining said minimum viable product. It’s not easy to do, mostly because defining a minimum viable product involves balancing 2 mutually exclusive terms. That said, I think you can find the best set of tradeoffs en route to the minimum viable product by examining the principles behind each part and then combining them back together once we understand what we’re looking for to satisfy each keyword.
Automatic software testing is an interesting thing. Books have been written on the topic, libraries have been built to try to bring the practice to traditionally hard-to-automate sections of testing, and in some places, it’s so important it’s the first code that gets written. There’s a lot of different philosophies about how it should work, but in my experience, it’s probably an area where the less religious you are about it, the better it’s likely to work for you.
Java 8 introduced a lot of cool features, 1 of the most useful of which was the
stream() method. This nifty little method lets you treat an Iterable as a stream, enabling cool things like lambdas operating over a list. Related to
parallelStream(). This lets you group your stream into smaller streams that are run in, you guessed it, parallel. Specifically, your data is processed in a thread pool the size of the number of cores on your machine, minus the one running your app. That’s a handy piece of information you’re going to want to keep in mind before you start throwing this nifty little call around in your code.
Software development is all about making tradeoffs. Sometimes, we do stuff because it’s quicker and get things out of the door faster, not because it’s the best option long-term. Do software development long enough, and you’ll learn the term “technical debt” – which is formally defined on Wikipedia as “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution”. A more informal, but probably just as accurate definition could also be “the price(s) you’re paying now to have shipped things earlier.” Here’s the thing, most of the time we do something that incurs technical debt, we know it then. It’d be nice if there’s a way for us to log the decisions we made, and the debt we incurred so we can factor it into planning and regular development work, instead of trying to pay it off when there’s no other alternative.