Even the smartest and most experienced developers make bone-headed mistakes, the kind that require hours of painful debugging only to find a comma was misplaced, or a one should have been a zero. While a good amount of effort should go into avoiding these errors, the energy required to prevent them completely would be astronomical. A better approach is to balance prevention and detection, hence the importance of good peer review and solid automated testing.
I keep a running list of topics, but today I’m ignoring it and shooting from the hip. A stream of consciousness post, if you will.
Yesterday evening I added a couple new features to an Ionic app. I’m really appreciating the improvements brought by Angular 2; it’s made the architecture quite a bit cleaner than before, and adding new capabilities is quick and painless. I still have a ways to go before I fully grok observables, but I’m getting there.
Was talking with a musician friend of mine on Sunday about the difficulty of making meaningful progress on a project without having at least 2 continuous hours of focused time to work on it. Half hours here and there don’t cut it. That’s an important truth both for us nerds who try to do side work in our spare time. It’s also an important reminder for non-nerds who feel the need to interrupt the nerds in their charge.
Speaking of interruptions, nearly 6 hours passed since I wrote that past sentence due to an urgent production bug. Who knew when I woke up this morning that by noon I’d be decompiling Java classes from a production server. Yay!
The Internet is a funny place. Yesterday was the first weekday in some time that I didn’t write a post, yet I had the most page views in a single day since I created this thing. Apparently someone (or some-bot) in Canada decided to read every single post I’ve ever written. A roughly similar thing happened a few weeks ago, when a post I spent quite a bit of time on got only a handful of views, while the filler I wrote the next day got three times as much traffic. I’m not complaining, just observing that it can be difficult to predict how consumers will respond to a product.
I think there’s a lesson there for aspiring software developers (and really creators of all types). Don’t get too hung up on numbers or popularity. Don’t think less of yourself just because your app didn’t blow up like Facebook or Instagram (those guys will tell you that was luck as much as it was hard work). Simply do the best work you can.
When I decided to revive this blog, I wanted to post daily for two reasons. I figured it would draw more traffic to have more content, but more importantly, my writing muscles had atrophied and needed regular exercise. Ultimately this whole thing is for my own enrichment, but if it helps others, great.
Customers are a finicky bunch (they’re human, just like everyone else). That means they’re not always right, and any business practice that assumes they are is likely to fail in the long run.
Don’t hear me wrong, I’m not saying that software engineers shouldn’t listen to customers. Nor am I saying businesses shouldn’t careful consider their customers’ demands and in certain situations give in. I’m really speaking more to an attitude of continual acquiescence. That’s not helpful for a customer who may not have the skill to evaluate what he wants, and it’s not healthy for a developer when they see their professional opinions thrown to the wayside.
If a relationship isn’t a two-way street, it’s probably not worth having.
Writing requirements is hard. Rarely is enough thought put into them, and even when a lot of time is spent, gaps are inevitable. Thus the most important feature to build into a system’s architecture at the beginning is the ability to change. Without that, all other features will quickly become obsolete.
I’ve had the opportunity to perform a bunch of job interviews in the past couple of years. It’s been a tremendous learning experience, and I’ve enjoyed contemplating the various psychological factors that go into both interviewing and being interviewed.
My quip from a few days ago was mostly tongue-in-cheek (sorry, dear wife), but if you do want to impress me in an interview, take some time to tell me everything you don’t know. Yes, you read correctly. I want to hear about your ignorance.
You see, there’s a well-documented psychological phenomenon called the Dunning-Kruger effect. It’s a cognitive bias where the incompetent person, due to their incompetence, lacks the skill to evaluate their own shortcomings, and hence overestimates his own capabilities (the opposite effect is known as Imposter Syndrome). I’ve seen these play out time and time again as I’ve evaluated job candidates; in fact, I know of no quicker way to get a general sense of a person’s skill. Besides, describing shortcomings demonstrates humility and self-awareness, two valuable personality traits in any field.
The domain of software development is immense; no single person can possibly know even one-tenth of one percent of what can be known (we’re all only human). The best developers know this, and can describe the boundaries of their own knowledge. Those who cannot probably have no idea what they’re doing.
Do you use Kubernetes as much as I do? Then you might find these scripts handy.
If you can go an entire job interview without using the words “just” or “basically” I will hire you on the spot.
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.
Simple is hard. Consider the following:
I guarantee an order of magnitude more work went into the first two of these three interfaces.