A World Without Email
By Stephen Darlington
| Feb 12, 2024
| books
Peter Drucker argued in a 1999 essay that the obsession with industrial improvement in the 20th Century is what lead to the productivity increase of manual labor by a factor of fifty between 1900 and 2000. Exemplified by Henry Ford’s transforming the manufacturing process of the Model T from the craftsman style that other auto makers used to the assembly line, this tinkering with workflows produced more and better work overall.
Digital Minimalism
By Stephen Darlington
| Feb 6, 2024
| books
Digital Minimalism by, Cal Newport is about re-examining your relationship with technology. Far from being neo-Luddite, Cal Newport is asking us to be more mindful of our consumption of social media, smartphones, and the 24-hour news cycle. As he says in the conclusion, “Digital minimalism definitely does not reject the innovations of the internet age, but instead rejects the way so man people engage with these tools.” I think that’s the key to everything: these things are tools.
Paying Down Technical Debt
Ask any five developers what “technical debt” is and you’ll likely get five different answers. To some, it’s an outdated framework and/or coding pattern. To others, it’s code that’s hard to work with. To still others, it’s the result of cutting corners to meet a deliverable. Let me throw out another definition: all code is technical debt.
Before you get out the pitchforks, give me a minute to explain. That outdated framework?
Infrastructure Monitoring
As software developers, we like to build cool new things with fun technology and the most cutting-edge techniques. But when applications are released to production, things can get hairy pretty fast. There are plenty of great tools to help you track uptime (Pingdom) or allow you to sift through traffic logs (SumoLogic), but sometimes the infrastructure will cause issues that aren’t readily apparent in these tools. That database query you wrote will misbehave when there’s a lot of data.
Software Development: Career Path
My last post was mainly about sharing my love of books, but my structure of organizing books into career tiers struck a nerve with some readers. As I am at the halfway point of my career, I’d like to offer my perspective on the career progression of a software engineer.
Software Engineer I This is also called Programmer/Analyst at some companies. This will be your first job out of school. You’ll be mainly given bugs to fix and small, (hopefully) well-defined tasks.
Software Development: The Books
Part of the job of a software engineer is to keep learning. The development discipline is still relatively new and changes come frequently. Not only are there new frameworks and technologies sprouting every day (how ubiquitous has Docker become in the last decade?), but also new patterns and best practices of how to build software and software systems. There are slews of talks on YouTube and online courses, but sometimes nothing beats a book for a good, deep-dive into a topic.
Architecture Decision Records
How many of you have gotten deep into debugging some production problem and said “Who wrote this crap?”? How often did it turn out that you yourself wrote it? At the moment in time that you designed the thing (system, database, algorithm), your choice probably made sense. But once customers got a hold of your software, realities set in that exposed a flaw in your design. It’s because when you made that design you were in the wide part of the Cone of Uncertainty.
Choosing the Right Architecture
There is no perfect software architecture.
Architecture, like economics and life, is all about trade-offs. The solution you’re building has to deliver both the functional and non-functional requirements the stakeholders need. It doesn’t get said enough, but the engineering team is also a stakeholder in the project. The functional requirements are easily understood: they are the specific things about your application that delivers the business value and makes your company money.
Automating Git
In software development, there are a lot of repetitive tasks. For example, creating releases in git, creating hotfix branches, etc. Because developers are lazy (read: efficient), we like to create scripts to automate things. To that end, I’ve created a couple small python scripts to help you automate this.
Your branching process may be different from this, but here’s an example workflow:
You branch from main to do your work. You work on your feature.
Hello, World
By Stephen Darlington
| May 29, 2022
| general
Welcome to the world of the DotNet Pundit. This is where I’m going to talk about technology, software architecture, productivity, and the latest cool things from .NET Core.
So grab a tasty beverage, sit back and relax. If you’re not careful, you might learn something along the way.