Articles about being a professional software developer.
Articles about being a professional software developer.
How do you tell when you are finished working on a change you are making to the code on your current project?
Nearly 15 years ago, I found myself with a particular problem at work. I felt like I was not being very productive, so I started closely tracking where my time was going.
It seems that the details of the eighteen people in New Zealand with positive COVID-19 tests have been disclosed, and officials are speculating that it may have been due to human error:
We have a poor habit in the tech industry of glossing over the complexity of things. Sometimes this is done deliberately, but very often it happens accidentally, as the result of skipping due consideration, or at a subconscious level.
There’s a very clever piece of design advice that I was taught at university that seems to be less well known than I expected.
Chatting with some fellow developers over the Christmas period, the subject of the so-called “soft skills” came up and one of them made a very interesting observation - that those skills lead to better code as well as better collaboration.
What do you do when you find a bug in the system you’re working on? I suggest that how you address the bug is a key measure of your professionalism as a developer.
One of the most useful precepts that I use to guide my development is this: when something goes wrong, make sure you fix it twice. This is especially important when the problem impacts on a production environment, but it’s also relevant for staging, testing, and development environments.
In our last discussion we talked about the cost of leaving a minor bug in place, versus the cost of fixing it properly. We discovered that the fix might involve half the time investment of leaving the bug in place.
I hope you’ve been considering the puzzle from my last post about how much effort it you should put into fixing a simple problem.
Imagine that you have a recurring problem in your production environment, one that occurs around once a week. The problem is fairly minor and affects only one user at a time. You can fix the underlying data issue pretty quickly with some custom scripts you wrote. What’s your threshold for fixing the problem permanently, instead of manually fixing it each time it happens?
Most people would agree that gaining experience is vital to career development, and I’m sure most managers would contend that their hiring decisions are, at least in part, driven by finding people with relevant experience to contribute to their team and their business.
Reading An Experiment in Think-First Development on the AgileKiwi blog has set me to thinking about the nature of software development and why it is that we do the things we do.
I was reading The Rules of Attraction: Location on Mark Seemann’s blog when I had a thought: Every Team is Distributed.
In my last post we explored a number of common approaches to documentation and the ways that they fall short. Fortunately, the story doesn’t stop there - we can (and should) do much better.
I’ve been asking developers I know whether they think their current project is properly documented. Not one of them has said that they’re happy with the documentation they have and most have talked about the need to write more. I suspect the problem is not one of volume, but of accessibility.
It’s well known that the human mind takes a lot of shortcuts - it’s one of the ways that it achieves the extraordinary levels of operation that we collectively refer to as “intelligence”. These same shortcuts also lead the mind to make some interesting mistakes - a rich field of quirks ripe for the both ethical researcher and the unethical conman.
A developers choice of keyboard is an intensely personal one. Some people favor the original IBM Model M with it’s mechanical key-switches. Jeff Atwood feels so strongly about the importance of choosing the right keyboard that he created his own.
So I have to ask whether Adam Bertram, over on the Pluralsight blog really has a point to make or whether he’s just creating linkbait to drive traffic. (I hope it’s the former, since many of his other blogs are quite worthwhile.) For a start, Adam asks a simple question - the same question that I posed as my title - Full stack developers: Do they really exist?
In my previous post we established that a key factor in professional software development is delivering value to the business - that we are constructing a business asset and that we should be building the greatest possible value into that asset.
Think about what you’re doing when you next write a test, code a feature or fix a defect. Why are you writing that test, coding that feature or fixing that defect?
It’s a curious thing how many developers - and other people in the ICT industry - have a problem with change.