Today, I was reading some advice from Simon Sinek. He says we should always work to outdo ourselves. Don’t focus on others, don’t strive to be number 1, don’t compare yourselves to others, compare yourself to you. Are you making progress? This is great advice in the tech world as well as the business world. Sure, I can be disappointed that my company isn’t as big as Microsoft yet. Or I can compare where my business is today to where it was last year and ask if I’m making progress. If you are a programmer, is your code better today than it was a year ago? If you are a system administrator, are you better with Windows administration than you were a year ago? If you’re a network admin, do you understand Cisco routers better than last year? If the answer is no, why not? Unfortunately, too many people in the world today spend too little time advancing their skills. Then, when it comes time for a raise, they wonder why they didn’t receive what they expected. How do you make progress in the tech world? It’s actually not hard. Read books, see what people are posting on Twitter, write code (if you’re a programmer), attend conferences, tinker with new hardware, etc. Skill only comes with practice! I read someone else say that things are either green and growing or brown and dying. This is certainly true of skills. Use them or lose them. If you’re not advancing your tech skills, those skills will atrophy. If you want to achieve excellence in your field, challenge yourself to be better today than you were yesterday and then take action to ensure it happens!
Management and Leadership
In the late 90’s, I attended the Army’s Primary Leadership Development Course, which was a requirement for promotion to Sergeant. This 4 week course included classes on leading physical fitness training, marching troops, compass and map reading (including a required night land navigation course), and other tasks necessary for leading soldiers in battle. Throughout the courses on leadership, the distinction between a leader and a manager was made clear. Of course, outside the military, I think most people would say they are synonyms. In the Army, leadership is defined as direct management of troops while management is indirect. What does this mean? It means that a leader directly interacts with his or her subordinates and a manager does not. A leader eats lunch with his team, a manager does not. A leader knows what’s going on in the lives of his team, a manager does not care. I don’t want to infer that management is in some way bad. We need managers – people in positions behind the scenes that move the wheels of an organization. But even more so, we need leaders. We need people who others aspire to be like, a person who inspires his team to great things, an individual that encourages others to be more than they currently are or even think they can become. For a leader, an individual will work extra hours, come in on Saturday, and end up being happy about it! In my entire career as a software engineer, I have found few people that meet these ideals. I’ve seen many managers, but few actual leaders. Indeed, in the software world we see titles like “Director”, or “Scrum Master” – neither one shows any sense of leadership. The title “Scrum Master” would never be chosen by a real leader because it suggests an incredible amount of superiority over the team. Leaders are part of what’s going on. They are doing what they tell others to do. They are protecting the members of their team. They are encouraging their team to do more. They are not above the action, they are an integral part of the action! Aren’t those the people you want to work for? The people you hope to be like? If you want employees to take your business to the next level, employees who are committed to your organization, empower them by ensuring the leaders you pick know how to lead – not just manage – those in their care.
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.