Retro Tech

In this age of tech, people marvel at artificial intelligence, robotics, smart watches, and the new iPhone. These things are all exciting, but some technologies of yesteryear are exciting in a whole different way. For example, it seems that record players are making a comeback. I would have never thought that! I remember when CDs came out – and who would ever want to go back to anything before that? Now, my daughter has a record player and I am absolutely spellbound by it. The thought of a ridiculously small trail of bumps on a piece of plastic that make sound is incredibly fascinating! What makes it more interesting to me, as a tech hacker, is that I can understand how it works. I could maybe even make my own with a servo and a few micro-controllers or maybe a Raspberry Pi. Much like gear heads who love classic cars because they can understand the hardware, the technology behind the record player is understandable to the average person. My favorite retro tech is probably the Nintendo. Not the Wii or the Switch – but the original Nintendo. I like the new Mario and Zelda games as much as any gamer can, but the original NES will always be my favorite. The simpler games that could be accomplished in an evening and didn’t require cheat sites and strategy guides sure were fun! Another interesting piece of yesterday is the Tandy 102 computer. A small laptop with an LCD screen and 4 AA batteries, it’s a piece of tech I still grab to tinker with sometimes. In fact, I’m getting ready to setup interface between the RS-232 port to an Arduino controller. Sure, the Tandy 102 only has 29K of “drive space”, but the built-in serial port and modem program makes it great for tinkering with hardware.  I originally bought it to interface to a ham radio with a radio modem. I could take the handheld radio and the Tandy 102 up on top of the mountain and read a ham radio BBS or communicate with other hams in text modes. On of my current projects is building a replica Altair 8800 from a kit. Not the most practical, but I’m looking forward to tinkering with a replica of an older computer and gaining a better understanding of older computer architecture and software.  When you’re looking at tech gadgets, don’t forget all those gems from the past! Some are still useful, some can provide educational opportunities, and most of them are just fun to experiment with!

Bring Your A Game

Recently, I was contacted by an individual leading a group of young engineers into a state-wide competition. This leader wanted to discuss the project and see if I had any advice. I provided him a simple improvement that would have greatly improved the product that the team was working to produce. Then, a few days later, I heard that he had decided not to take my advice. Instead, he would use my suggestion as an improvement if his team was selected to advance to round two of the competition. This really disappointed me. This leader has taught his team to try just hard enough – not to do your best. And, he made the mistake of assuming that his inferior product would advance to the next round. In today’s highly competitive market, this is the exact opposite of what the next generation needs to see. Instead, we need to install in those underneath us a quest for excellence – not mediocrity. If you can do better, why aren’t you? If you can make the product better, what’s stopping you? Innovation and excellence require pushing yourself every day – you can never settle for anything less. In everything you do, bring your A game. If you don’t, someone else will and you’ll be left on the sideline.

Counting Lines of Code

Often times, while writing software, it’s useful to know how many lines of code exist in a project. While this is a poor metric for gauging a developer’s output, it can be useful in getting a feel for the size of a project. It may also be useful in comparing different languages. For example, how much more concise is Kotlin than Java? Unfortunately, there are no built-in tools for doing this calculation. So, how can you easily count lines of code? I use a simple shell script – which will work on Linux or Mac, to count my code.

#!/bin/bash

extensions=(bas c cc cob cpp cs fth f90 go h html java js jsp m pas php pl py sc sh sql xhtml)

for extension in ${extensions[@]}
do
  lines=`find . -name "*.$extension" -type f -exec cat {} \; | tr -d '[:blank:]' 2> /dev/null | grep -v '^$' | wc -l `
  if [ $lines -ne 0 ]
  then 
    echo $extension: $lines
  fi
done

You can add additional language support by adding the file extension to the extensions list. Then, run this script from the root directory for the project to see the code count.

Planning & Execution

January is a month when people plan changes for their life. Some will change their diet, others will start exercising. I have decided to focus on setting and meeting my goals this year.  Having a full-time job in addition to running my own business leaves little time to be wasted – so I really need to be intentional with how I spend my time in order to achieve my goals. In order to learn how to better achieve my goals, I have been reading books and watching videos online. One key point I see over and over in achieving goals is to take action. You can’t talk about what you’re going to do – you need too start doing it! This applies to anything in life – but today I was pondering how it applies to software development. If we want to release a piece of software, we have to start writing software. But here’s the problem – all too often is seems that too little time is spent planning how to write the software. We focus so intently on the end goal of releasing a software application that we ignore coding standards, fail to document code, avoid refactoring, etc. In the end, we meet the goal – but we end up with unmaintainable spaghetti code. So, while we may have met the goal, we end up ensuring that future development will take more time and be littered with potential problems. And, ironically, while we met the original goal, we could have likely released early if we had simply spent more time upfront planning direction of the code, determining good data models, etc. So, while inaction will paralyze any project, improper action will will end up being just as counter-productive.

Bad Teachers

Today, more and more tech realms require a bit of programming knowledge. If you’re a QA, you may be writing test cases in Python or Java. If you’re engaged in Devops, you may be writing scripts or code for automation or other tasks. If you’re a hardware hacker, you may be writing C++ code for an Arduino board or Python for interacting with GPIO pins on a Raspberry Pi. Unfortunately, most of the code written by QAs, devops teams, and hardware hackers is not up to the standards of good software engineering. Indeed, all of the above fields are more software hackers than real engineers in the software realm. What that means, is that when you view tutorials or documentation created by people skilled in areas outside of software engineering, that you’re likely learning poor coding standards. Of course, it’s seems hardly fair to hold QAs to the same standards as you do software engineers. But the problem comes later when the QAs say “I know Java.” Or when the hardware hacker says “I can program in C++.” Now, you end up with bad code entering your codebase because of untrained developers. I want to be clear – my point is not to discourage QAs and devops teams from programming. But rather to encourage developers to assist programmers in these fields to adopt proper coding standards. Treat there code with the same scrutiny you would a developer – subject it to code reviews, and demand proper coding standards. Otherwise, the same problems that plague software projects will end up causing problems in your devops environment or your QA testbed. Don’t assume that a QA can program in Java because they’ve written some test cases. After all, you wouldn’t trust me to replace the engine in your car just because I’ve changed the spark plugs in mine.

Coding Standards

When I look at code developed by other developers, one of the things I first notice is if the code follows standard coding conventions. For some languages, like Java, coding conventions are very standardized. For other languages, it’s a free-for-all. However, few things are more important to the readability of code than standard coding conventions. Image, for a moment, how important conventions are when reading a book. Capital letters start sentences, periods end sentences, and rules of grammar dictate the order of words. Similar conventions apply to code – variable names, function names, class names, spaces between symbols, etc. Why is this so important? Because when you look at someone else’s code, you expect to be able to read and follow the code. If the writer is using different conventions, it takes longer to read and understand the code. Then, if you edit the code using your own conventions, the code quickly becomes unreadable as every developer uses their own standards for different pieces. Ultimately, you should never be able to tell who wrote a piece of code since everyone should be following the same rules. And when everyone follows the same rules, developers can more quickly find and diagnose bugs as well as add new features. When I work with new developers, coding standards are among the first things I drive home!

Serving Customers

One of the most important things to most customers is customer service. And how do users rate customer service? Typically, by two criteria – the speed at which results are achieved and how satisfactory the results were. You can look at review websites for any product or service and see people complaining about one or the other. As consumers, we want what we want, and we want it now! Of course, there’s nothing wrong with that – capitalism encourages such a model.

But here’s the problem I see in my business – consumers who want something, but won’t communicate what it is they want. Or consumers who are quick to complain about an issue but won’t provide the information to resolve that issue. I have customers who will send me an email about an problem wanting it immediately fixed. But when I send email after email to gather more information, they are ignored. Then, the customer sends me another message asking if their problem is fixed. I have software customers who will report a high priority bug, but won’t tell me how to reproduce it and ignore emails from the ticket tracking systems.

Fortunately, the resolution to the problem is simple: If you want excellent service from the companies you work with, be prepared to offer excellent service to those companies when they are trying to resolve your problem. Otherwise, you only get out what you put in – and that’s not the fault of the company servicing your problem!

 

Free Speech

This time last month, the internet was buzzing with Net Neutrality. Nobody wanted commercial interests injected into the internet, because the internet should allow people to be able to access what they want without impediment. The strange thing is, the internet has never been a particularly neutral place.  Today, for instance, a video was released showing a Twitter engineer talking about what they do to block or “shadow ban” pro-Trump accounts or people who support the 2nd Amendment. Last fall, Facebook was similarly called out for how they curated their news feed as well as their trending news section. And today, the Pew Research indicated that the US media bias is the worst in the world. Of course, Twitter, Facebook, and the US media are all corporations that have a right to do those things. The problem is – it’s not even remotely neutral in any way. Neither Twitter nor Facebook are neutral organizations willing to allow free speech on their platform – both are politically biased, and have used their platforms to further their political agenda. So, the net never was neutral. If you want a neutral internet, fight the companies that create the bias. Hint: it’s not Verizon and Comcast.

What is Refactoring?

To me, refactoring is one of the most important parts of the software development lifecycle. Most developers are familiar with the idea of refactoring, but customers and managers may not be.  So, what is refactoring and what value does it bring to the development process? Refactoring is the process of going through code and redesigning, updating, and fixing with the intent of improving the code. This can encompass a lot of different improvements. For example, a developer may find that certain blocks of code are repeated over and over again. Repeated code can cause all kinds of problems. At the very least it increases the size of the application needlessly, but on the more problematic size, it also decreases maintainability of the application. For example, if a code block is repeated 8 times, and the required logic for that code must change, the code will need to be replaced in 8 different places. Chances are good that developers will only find 7 and you’ll spend months trying to figure out where the problem is. Other common tasks involve redesigning to make the application cleaner, removing unnecessary code, and all sorts of things to generally improve the codebase. Why is this important, and what is the benefit to the organization? Without refactoring, code tends to become messy. Each new developer adds something new, code is duplicated, paradigms change, data models are updated, technologies are improved, etc. As these things happen, the application becomes increasingly difficult for developers to follow. Additionally, bugs increase, the size of the code increase, and things run less than optimally. In the end, refactoring is kind of like getting a tuneup on your car. As a good developer, I am always looking for ways to improve the code so that future developers will have an easier time maintaining the application. It’s incredibly important and should be a priority not only for developers but for management and customers as well.

Hacker Boxes

Every month, I eagerly await a package to arrive. It’s a small package, and it’s contents are always a surprise. What is it? It’s my HackerBox! HackerBoxes is a monthly service that sends you a box with some sort of tech project inside. Previous projects have included Raspberry Pi systems, Arduino micro controllers, GPS, circuits to connect to the cell network and so much more. This month, the project was to build and program an EKG device. An hour of soldering later, and I could measure all sorts of bodily signals. Through my monthly subscription, I have not only been exposed to new technologies (such as the amazing Micro:bit) but also been able to tinker with hardware at a lower level than I typically do – opportunities to tinker with circuits and hardware as well as the code that makes them work. It’s a great service, and one I would encourage all tech nerds to receive. While I may not make hardware for a living, the exposure to all the technologies I receive from HackerBoxes is well worth the price I pay.