One of my favorite technical projects involved overcoming a network constraint. The virtual machines (VMs) hosting the core services kept exhausting available ports. Once all ports were used up, new connections would fail, tanking our availability and reliability. Read on to learn how we overcame this issue and opened up opportunities to reduce costs by a third.
The book’s core thesis is minimizing complexity in software development by adopting complexity-eliminating approaches. The upfront investment in learning and adopting better designs pays off because it leads to high-quality software. Recommended read for software developers and line managers.
Most teams struggle with removing friction because they concentrate on surface-level reactionary fixes instead of addressing the fundamental causes of inefficiency.
When most teams complain about poor quality, they usually mean reliability woes; however, quality spans a more extensive spectrum and can mean many things. If you complain about your software being of low quality, what dimension do you mean? Use the Maslow quality hierarchy to identify the pertinent challenges and make the right tradeoffs.
There is a high chance that you attend or have attended an inefficiently-run stand-up. I have seen various stand-up styles over the years. Sadly, most of the roughly 2000 stand-ups I attended were unproductive. Mildly put, most were status reports for some manager or higher up.
5 important ideas that engineering teams need to keep in mind to optimize value delivery.
Constantly factoring deletes into your iterations keeps your code base healthy
My heuristic is to green-light full adoption only if the long-term benefits outweigh the costs and risks
These are a few strategies I employ to be more efficient at work.
There is more to software development than writing code. This post describes three of the most oft-repeated tasks I have been asked over the years. These are not strictly programming tasks but help magnify the impact.
My foremost goal while building software is to build stable self-healing systems with deterministic behaviour. I want to ensure my code continues to work even when unexpected events occur. In the event of unknown unknowns, the expectation is a graceful degradation in the worst case.
One of the most challenging aspects of software development is staging changes without breaking the service. Releasing new features always comes with a risk - bugs might be introduced and existing failure points might become more prone to failure.
Software engineers, technical leads and managers all share one goal - shipping high-quality software on time. Ambiguous requirements, strict deadlines and technical debt exert conflicting tugs on a software team's priorities. Software quality has to be great otherwise bugs inundate the team; further slowing down delivery speed.
I recently transitioned into a full-stack role - I wanted to stretch myself and step out of my comfort zone. The biggest challenge was my struggle to quell the quite nagging voice in my mind screaming 'impostor!'.
A couple of things to validate before you press the 'go-live' button on that wonderful web application of yours.
As part of my continuous learning; I started reading Tero Parviainen's 'Build your own AngularJS' about 6 months ago. After 6 months and 127 commits, I am grateful I completed the book.
Another classic rant again; yeah it's always good to express thoughts and hear about the feelings of others - a good way to learn.
Your wonderful one-of-a-kind web application just had a successful launch and your user base is rapidly growing. To keep your customers satisfied, you have to know what issues they face and address those as fast as possible.
I used to work for a team where whenever an engineer said he was done, the next question would invariably be are you 'done done'?
Looking back, I have learnt a couple of lessons the hard way and wanted to share some of these so that other engineers know what to avoid.
How to get consistent print output across a range of browsers and their never-ending stream of subtle nuances.
Programmers have to love their craft and put their best into making it stand out.
Five lessons learned from reading Code Complete 2
Programs do not acquire bugs as people acquire germs, by hanging around other buggy programs. Programmers must insert them... Harlan Mills Software breaks all the time: booting issues, corrupt software and files, crashes etc; nearly everyone has had a close shave or two with fragile software. Can programmers write 'perfect' fault-free software? I presume a trip to … Continue reading The Myth of Perfect Software
Clean code is what we developers should aspire to write, it is clean, minimal, simple, easy to understand, free of extraneous details,