The problem I described in my last post is relevant to more than just useless code comments. Check out these helpful and totally not redundant download instructions I found on a website today:
I sure am glad the extra text is there to clear up any confusion on which version I needed.
I wrote yesterday’s post almost a full day in advance, which hadn’t happened before in the (admittedly short) history of this blog. It felt really nice when my daily 9am writing reminder went off to simply click “Publish” and get on with my day, instead of hitting snooze and hoping I get back to it later.
It brought to mind my sophomore year of college, where I learned the value of discipline. My fiancée was at a school ten hours away, and I had a randomly assigned roommate with whom I had nothing in common (and despite his pedestrian physical appearance managed to have three simultaneous girlfriends for most the year, but that’s a different story). I also had a class schedule that finished by 2pm every day.
Since I had little reason to get back to my lonely little dorm room so early in the day, I got in the habit of hanging out in the library studying until dinner. I quickly discovered that this routine completely freed my evenings and weekends of schoolwork. And that was awesome. I wasted gobs of time playing video games during those hours, and didn’t feel the slightest bit bad about it, because my work was done.
There are really only two tasks a company must perform:
Each employee, no matter her job title or role, must contribute in some way to one or both of those two goals. Any other task is only a means to one of these ends; everyone involved does well to remember that.
And yes, I realize strictly speaking products and services are two different things, but for the sake of pith can we consider the latter a type of the former? Thanks.
(I’ve been asleep at the wheel for far too long here, time to dive back in with a truckload of mixed metaphors).
Do you get enough sleep? Americans are chronically sleep-deprived, and a body of research is growing that tells us how damaging a lack of rest is to every other area of life (see, for example, this fantastic article). The particularly troublesome aspect is how sneaky the damage can be, manifesting itself in subtle ways over time.
A large part of being a professional software developer is taking care of your meatspace hardware. And that means getting regular sleep. The image of the late-night coding warrior who bangs away at the keyboard until the wee hours of the morning may play well on TV, but it’s false. The most effective engineer is one who rests.
Yesterday I migrated a bunch of microservices from the baseline Node 6 Docker image to an Alpine Linux version that I custom-built to be as small as possible. Average image size went from 800MB to 80MB across the 6 services, for a total savings of over 4GB per deployment.
Not a bad way to spend a day.
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!