Thoughts on technology, movies, and everything else
I work in technology sector. And I do round a clock, not only from 9 to 5. It is my bread and butter, it is my hobby, it is the fascination of my life. And with the current rate of change particular in information technology (IT), there is always something new to learn, to try, to talk about. I often post news, thoughts, and reviews. And when I do, this is the category I use.
I came across these “Notes to Myself on Software Engineering“, with which I agree wholeheartedly. Some of these I’ve learned “the hard way”. For most of these, I wish I knew them earlier. They would make my life a lot easier. Here a few to get you started, but make sure to read the whole list, as many of these apply to other areas of IT and life in general.
It’s okay to say no — just because someone asks for a feature doesn’t mean you should do it. Every feature has a cost that goes beyond the initial implementation: maintenance cost, documentation cost, and cognitive cost for your users. Always ask: Should we really do this? Often, the answer is simply no.
Invest in continuous integration and aim for full unit test coverage. Make sure you are in an environment where you can code with confidence; if that isn’t the case, start by focusing on building the right infrastructure.
Simple things should be simple, complex things should be possible. Don’t increase the cognitive load of common use cases for the sake of niche use cases, even minimally.
Because code is communication, naming matters — whether naming a project or a variable. Names reflect how you think about a problem. Avoid overly generic names (x, variable, parameter), avoid OverlyLongAndSpecificNamingPatterns, avoid terms that can create unnecessary friction (master, slave), and make sure you are consistent in your naming choices. Naming consistency means both internal naming consistency (don’t call “dim” what is called “axis” in other places) and consistency with established conventions for the problem domain. Before settling on a name, make sure to look up existing names used by domain experts (or other APIs).
Career progress is not how many people you manage, it is how much of an impact you make: the differential between a world with and without your work.
Software development is teamwork; it is about relationships as much as it is about technical ability. Be a good teammate. As you go on your way, stay in touch with people.
When we find ourselves in a conflict, it’s a good idea to pause to acknowledge our shared values and our shared goals, and remind ourselves that we are, almost certainly, on the same side.
I am a big fan of social apps, especially those that address a particular problem, usually outside of the generic social networks. Unfortunately, many of these apps suffer from the same set of problems – insufficient user base to make them useful, competition from larger apps with overlapping functionality, and feature stagnation.
If I find the application useful, I try to ignore these problems for as long as I can. But, unfortunately, at some point even the best of us give up.
Waze is like a social network for drivers. There are plenty of maps and navigation apps, but Waze went further. The app had the functionality to assist with mapping the roads, reporting police and road hazards, and some basic social and gaming functionality, where you could communicate and compete with other drivers. (The competition wasn’t speed based, but rewarded drivers who contributed the most.)
Waze wasn’t shut down after the acquisition and the deal kind of made since, as Google would get real-time human contributions to compliment its automated ways of Google Maps.
But it didn’t solve the problems of Waze at all, if not made them even worse. More and more people started using Google Maps. The development of Waze slowed down to a crawl. And even the most vital features for such an app were never added.
As far as I was concerned, I could even live without the large user base. But there is one particular feature that kept annoying me until now, which was never added. There is no way to drop a pin on the map. Yes, that’s right, Waze is a map and navigation app without a pin. Instead, you can either search for places to go, or enter a street address to go to.
Cyprus is the country where street addresses are seldom used for navigation. Most of the cities grew out of small villages that overlapped with time. Which means, there is no preset design for the cities, like in the USA with the street-avenue grid. And most of the villages had the streets named after the same people, which, in the city causes lots of confusion with several streets in different parts, named the same. Heck, we even have streets with the same name crossing each other.
Try telling Waze that you are going to your friends house. You know where it is on the map, but you don’t know the exact address. (Yes, you might know the street name, but not the number.) And you’ll know what I mean.
On top of that, with fewer and fewer users contributing to the app, the data gets obsolete. There are places that have closed years ago. There are places that have moved to a different address. And there are plenty of new places that Waze knows nothing about.
And since you’ve got me complaining, here’s another feature that I miss, which is also missing or inadequately implemented in all the other apps I’ve tried – custom repeatable routes with multiple stop points.
Google Maps has a very basic “Commute to” feature, where you can just set your work and home, and then quickly navigate to either one or the other. Waze and many other apps have the same. But that only takes you so far.
Here are two scenarios which are a pain in pretty much every navigation app:
More than two commute entries. Yes, work and home are common destination points for most of the user base. But what about school? Many of us are not 18 anymore and need to drive the kids to or from school. Sometimes, even more often than we navigate to home or work. People might have more than two jobs. Or they might have other destinations that they visit on a daily basis. It might a doctor’s office, or an older relative for a quick check. Why not expand the short list of “Commute to” entries to more than 2. Make it 3 or 5, and that covers most frequent routes for most people.
More than two points in a route. Sure, home to work, and work to home, makes sense. But for over a year I had to commute to work, while picking up two colleagues on the way in, and dropping them home on the way back. Even dropping off the kids to school on the way to work is a common scenario among the parents I know. Why can’t we just connect the dots? Create a new route from one place to another, add a couple of stops in between, and save it in the shortlist for quick access. This will even help with the navigation part as well. The app won’t have to insist on re-routing me on every turn, when I briefly drive in the direction opposite to my office to pick up a colleague.
So for the last couple of month, I haven’t used Waze for my navigation needs. I tried a whole lot of other apps, and after a brief try outs, I decided to use Google Maps for now. It’s far from perfect, but it sucks less than others.
Oh, well. That’s good to know. But that just confirms my decision of letting Waze go and using Google Maps. At least for now. We’ll see what the future brings. Hopefully Google won’t kill the Goolge Maps app, like it did so many others.
Goodbye Waze and thanks for all the good times. I’ve enjoyed our time together, but now it’s time to drive forward. Hello Google Maps. Please learn from the mistakes of Waze. You’ve paid the money already.
I really liked “OPP (Other People’s Problems)” article which talks about handling of responsibility for things that other people should be responsible for.
If you’re reading this looking for advice, you’re probably a go-getter. You consider yourself a responsible person, who cares deeply about doing things right. Your care may be focused on software and systems, or on people and organizations, or on processes and policies, or all of the above.
This attitude has probably served you well in your career, especially those of you who have been working for a number of years. You’ve been described as having a “strong sense of ownership,” and people admire your ability to think broadly about problems. You try to think about the whole system around a problem, and that helps you come up with robust solutions that address the real challenges and not just the symptoms.
And yet, despite these strengths, you’re often frustrated. You see so many problems, and when you identify those problems, people sometimes get mad. They don’t take your feedback well. They don’t want to let you help fix the situation. Your peers rebuff you, your manager doesn’t listen to you, your manager’s manager nods sympathetically and then proceeds to do nothing about it.
That kind of grinding frustration can wear you down over time. I know, because I’ve been there.
Not only the article describes the problem, but it provides a practical approach to dealing with it.
In the last few years, I was going through a very similar thinking process in my head, but I’m nowhere near the well-defined suggested approach. I wish I read this much earlier in my career. Much much earlier.
SCAR is a deployment stack for static websites. It’s not exactly a single-click process, but it is as simple as possible. The name is the abbreviation from the Amazon AWS services which are utilized for the deployment: S3, CloudFront, Amazon Certificate Manager, and Route 53.
The whole thing is built via the Amazon CloudFormation, and shouldn’t require much of tinkering with the services or reading lengthy documentation pages. This bit should also motivate you to try it out:
How much will this cost?
For most sites, it will likely cost less than $1 per month. The cost for a Route 53 hosted zone is fixed at $0.50/month; the remaining CloudFront and S3 costs depend on the levels of traffic, but typically amount to a few cents for small levels of traffic.
These three facts all seem eminently sensible and reasonable, right? 1. Unix time is the number of seconds since 1 January 1970 00:00:00 UTC 2. If I wait exactly one second, Unix time advances by exactly one second 3. Unix time can never go backwards False, false, false.
All three of these are false and for the same reason – leap seconds. The article provides a nice and easy explanation of how and why that happens.