Any engineer worth her salt must learn to prioritize well. The next couple weeks are crunch time at the office, so my posts here will be spotty at best. My hope is that once things settle down I can dive into some meatier topics. But for now, superficiality rules.
Do you use Kubernetes as much as I do? Then you might find these scripts handy.
Last night I wrote my first Cordova Plugin (a little tool that allows an app to determine the local IP address on a Windows 10 device). I was proud of my success given limited documentation and a poor development environment (just a Surface 3 and command line tools).
What made me particularly excited, though, was that I could give my update back to the open source community via Github. Every developer on Earth has benefited greatly from the availability of high quality and easily modifiable free software, myself not the least. I enjoy every opportunity to give back in some small way, and I encourage all developers to do the same.
If nothing else, it makes your résumé significantly more attractive.
I was busy today doing actual work. It happens. See you Monday!
Yesterday I was speaking with a fellow engineer about the state of our new user interface implementation. We’d crossed a major functionality threshold, but there were still several obvious bugs. I argued that the significance of the functions that were working merited deploying to our integration server for others to see, but he resisted saying that he’d rather wait until a couple of the blatant problems were ironed out.
The above is a common conundrum for developers. Put your work out there for others to see too soon, and they’ll be quick to point out all the flaws. Wait too long, and managers start breathing down your neck because they’re not seeing tangible results.
Personally, I think the wise manager understands the idea of a work in progress, and should appreciate seeing said progress without getting overly critical of early blemishes. It’s a bit like posting photos of a newborn baby. Obviously everyone loves their little nugget, but reality is most newborns aren’t super cute in their first couple of days. But would anyone ever dare point that out to proud parents? Let’s surely hope not! The birth of a child is a momentous event to be celebrated; there’s plenty of time later for the kid to grow into his adorableness.
Likewise a software application. Publish early, and let that baby grow!
I’m taking a day off from writing today. See you tomorrow!
(Yes, I understand the irony of this post)
“If we look at our work immediately after completing it, we are still too involved; if too long afterwards, we cannot pick up the thread again.”
A big challenge for managing a software development team is the problem of context switching. Interruptions in general are productivity-killers, and it’s especially true of a discipline that requires sustained focus like coding.
But in addition to small-scale interruptions (of the 5-15 minute variety), large-scale switching of priorities can also have a disastrous effect on productivity. I’m thinking here of diversions of the 1 day to 1 week variety. Frederick Brooks couldn’t have been more right:
“How does a large software project get to be one year late? One day at a time!”
(You have read The Mythical Man-Month, right? If not, get thee to a library immediately. It’s required reading for anyone in the software profession).
I do my best to take the above warnings to heart, but it can be tough in the day-to-day realities of production bugs and last-minute requests. One way I try to mitigate is to serve as the buffer between my team and these sorts of interruptions. No doubt there’s a huge cost to my productivity, but I can plan for that when I recognize it as a critical part of my role.
Pascal’s observation has a second application to software development, one held in tension with the “no interruptions” philosophy: sometimes a developer needs to take a break from her current tasking to get refreshed and refocused. This can play itself out in a number of ways, whether it be jumping from front-end to back-end development for a few weeks to avoid getting pigeon-holed, to taking a half-day to go through a tutorial on a new technology, to simply grabbing coffee for 30 minutes and getting out of the cubical. Project planners would do well to build in significant amount of “productive diversions” into their roadmaps, and front-line managers should not get grumpy when they don’t see developers at their keyboards 9 hours straight.
Ultimately my philosophy is simple: trust your team to be professionals, and let the results be your guide.
Don’t think I’ll normally write on weekends, but thought it worth stopping by to say so, lest my throngs of anxious readers go wondering.