Three things about January

Just before I went back out to work in January, I had a fair sense of how I wanted to start the year. At work, I’d be diving in to Planner and refining some early 2020 goals that Anand and I had come up with. At projects, I’d be doing some arduino and bot stuff. All great.

But from January 2nd, I found myself very deep in legacy code from at least a decade ago. And I was working very late. It’s like time stood still. When my team and I raised our heads for a week, a change to the environment around that same code meant even more speelunking.

Out of this last few weeks I saw three things of note:

try
{
//actual code to do something meaningful
}
catch
{
//empty, meaningless catch block
}

  1. Stop using empty catch blocks.
    I haven’t had cause to leave dangly, useless catch blocks lying around for a few years, but I remembered when I used to. And boy was it a shocker. In the age of amazing tracing tools like App Insights, throwing away trace opportunities was like a slap in the face.
    When I showed a few developers at work some examples of empty catch blocks, they understood why it might have happened – I didn’t know what I wanted to do with the exception at the time – but my response was largely, “well, at least log it na”. At least. Even logging took a hit this month.
  2. Log with sense
    The worst kinds of exception message in a log is “An exception occurred”. For the most part, sometimes, when looking for the flow of a problem, I might just put a log statement to show that we got to a place in code. Sometimes, that place is an error handler. The way I see exceptions now, if you’re logging that it occurred, take some time to log what that block was trying to do, as well as what parameters are available. In a messaging system for example, simply a message Id is a big deal. So, first we log, then we log with sense.
  3. Sleep is very good.
    Not just sleep, but a firm commitment to not rush off with the first good idea you have when facing a problem. I have actually heard this stated another way, “Beware the danger of the first light”. While trying to debug our way out of the hole we were in, several ideas came up. Most recently, I had a great one that would have led to massive changes in the system. I was about to announce it, but one of the managers on our team cautioned me. She said it was Friday, sleep on it and see if you feel the same way on Monday.
    Monday came, I felt the same way. Until I spoke to one of the newest engineers on our team and realized we could achieve what I wanted to with a change to one module, as opposed to the whole system. That was good.
    Over the course of this month, there were a lot of challenges.

A short note on value-based pricing

This is a short note because I’m not an economist and don’t pretend to be one. I think areas like pricing and value and cost determination are complex and should be given their just consideration, however, I recently saw a question on Caribbean Developers and I wanted to share what insights I have on it.

When I first saw this, I knew immediately I wanted to say, “Aye Roger, lean away from thinking hourly rates”, but that felt a bit too curt.

It’s been my experience that freelance developers tend to think in terms of charging hourly rates and doing work that they cost based on that rate. The “better” or more experienced they get, the more the rate reflects their growth/maturity in the space. Then, they learn about markups, based on their understanding of customer risk and that good stuff. But I’ve come to appreciate that thinking in terms of hourly rates for the work you do in freelance is a trap. The actual term for what I think is a better approach is value-based pricing.

I found a great explanation of it on quora:

Value-Based Pricing means presenting a price to the purchaser which is based on their perception of the value they will derive from the result being discussed

More from David Winch, Pricing Coach on quora.

So, I think Roger needs to spend time understanding how to develop a firm that uses Value-based pricing. It’ll help much more in the long run.

After Roger posted his question, I saw a great point from @sehelburt on the matter too:

Teaching (again)

Last year, I taught three courses.

  • Intro to Mobile Applications
  • Software Engineering
  • Cloud Technologies

I hadn’t done any lecturing for a while, and the opportunities came around fairly suddenly, but it was good to be back in class and sharing experiences. Mobile Apps & Software Engineering were taught at the University of Trinidad & Tobago.

I’ve found that interacting with the students and faculty is excellent for understanding how important the relationship between industry & practitioners and institutions can be.

That’s it for now, but I’ll write on Cloud Technologies another time.