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.
Continue reading »One of the benefits of using Javascript frameworks like React or Vue is that you can build and export your own custom components. This lets other teams in your organization or even external developers build front-ends that have a consistent look and feel across the board as well as follow any style or branding guide you have. That’s great, but think about the components you’re putting out there for developers to use. Are you putting out the bare minimum or are you shipping front-end tools that speed development up and make people’s lives easier (you know, the whole point of shipping front-end components like this)?
Continue reading »Do any research into current front-end development, and you’ll hit React pretty quickly. As far as modern Javascript frameworks go, React is probably the standard Javascript framework used by startups and other companies that haven’t already heavily invested in another front-end framework. While React does a decent job of packaging up HTML and Javascript into reusable components, there’s been some design decisions around handling application state in React, namely by using a framework called Redux, that make developing applications harder than it has to be, and make it worth your while to look for other options before you start falling into its rabbit hole too.
Continue reading »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.
Continue reading »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.
Continue reading »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 stream() is 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. Continue reading »
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.