Hey! Welcome to this month's newsletter. Software development is a field where hype is big and it feels like everything moves fast – at least at the edge. In the real life projects though, the speed is notably slower and the old tried and true methods hold strong. This month's newsletter is a reminder that not everything in tech changes every week.
Minna is a software developer who thinks true software developer skill can be measured by how much code you delete. She pretty much hates programming, and thinks there is too much software in the world. This curation will contain only classical content, because things were better back in the old days.
As we saw above, not all methods for creating software are equally good. One frequently mocked and underappreciated method for creating a System out of software is the monolith. In this article DHH explains why you should favor the monolith over microservices nearly every time.
A thoughtful ponderance on how we build software systems from 1999, recognizing that systems are ever-evolving and imperfect. Note that this piece was written two years before the Agile Manifesto.
“In the software world, we deploy our most skilled, experienced people early in the lifecycle. Later on, maintenance is relegated to junior staff, when resources can be scarce. [...] If the hypothesis that architectural insight emerges late in the lifecycle is correct, then this practice should be reconsidered.”
One of the most excellent ranters on the internet, Steve Yegge, intended to publish this piece internally at Google on Google Plus. Remember Google Plus? Hahaha.
Anyway, he screwed up the settings and ended up posting it publicly.
The text covers many themes, and each reader may get something different out of it. For me, the most interesting part is the origin story of AWS.
Error Boundary is a React component that catches JavaScript errors anywhere in their child component tree, which enables graceful handling of runtime errors and offers a way to recover from them. The way it is used makes it important to have it well-tested.
In this edition of TechWeeklies, Layla talks about what error boundaries are and why they are a valuable tool in your React toolbox. She also builds you an example of how to test those error boundaries with React Testing Library using Test-Driven Development.
Are you looking for the next chapter in your career journey? At Futurice, you can travel in great company. We’d love to hear your software adventures in faraway sandboxes with exotic code languages. Perhaps you’ve come to realise that it’s time to head back home, but not to lose your freedom. To work remote, but stay near the action...
As a lead developer the focus shifts more towards consulting, although it depends a lot on the project how far exactly. We typically lead by example, for instance by showing how lean principles bring fast results. All development teams are self-organising and make technical decisions together...