Today, I was read an article asking why you do whatever it is you do. If you are trying to sell to a customer, they’re not interested in what you sell but rather why you sell it. You may sell widgets, but people don’t buy widgets for the sake of having widgets – they buy widgets for whatever it is they do – the why. In my business, people don’t buy code – they don’t care about code. What they do care about is the why. Why do I write code? I write code to simplify business processes, to improve operational efficiency, to increase revenue, to ensure compliance with regulatory guidelines, and to simply make my client’s life easier. People buy those things! As a business, wouldn’t you pay for operational efficiency, increased revenue, and easier compliance management? Software can have an impact on every facet of a business and take your business to the next level. Don’t waste your time doing tasks that aren’t generating maximum revenue for your organization – find software solutions to solve those problems so you can spend your time having a real impact on your business by focusing your talents where they will generate the most revenue!
Finding Tech Jobs & Candidates
Scrolling through LinkedIn, I see people talking about how they can’t find jobs. Talking to companies, I hear how they can’t find qualified candidates. This seems to be the story all across the nation regarding IT positions. How can this be? Why are businesses unable to find candidates while there are candidates out there looking for jobs? As a software engineer and small business owner, I often look at job boards to see what companies are looking for, what trends are hot (based on something more than just twitter hype), and what direction the market is headed. Over the years, a few things have become apparent to me. First, software companies are constantly looking for employees that meet an absurd number of qualifications. Their requirements start to look like the checklist for a set of collectable cards. Is it really necessary for the candidate to be an expert in 15 different technologies? It’s particularly difficult now because of the sheer volume of technologies available for use. Languages, web servers, front-end toolkits, build environments, continuous integration environments, libraries, project management methodologies, and the list goes on. And under each of those categories, dozens of choices – C, C#, C++, Java, Scala, Python, PHP, etc. Eventually, job posts end up with so many requirements that you are literally looking for a needle in a haystack during your candidate search. Employers: Do you really need an expert in all those different technologies? I doubt it – you need a solid programmer who can learn the technology stack you have in place. The second thing I’ve observed over the years is that few developers actually have a drive to learn new technologies. How is it we still have programmers and other tech professionals that don’t know Linux? How can you be a software engineer and not have some knowledge of JavaScript? How many shops are using toolkits and frameworks that died years ago? Delphi is still out there, but would anybody actually chose to start a new project with this antiquated technology? Too many developers are stuck in their world – “I am a Java programmer, I use Eclipse on Windows, and I know Maven”. On both sides of the equation – companies and job candidates – there exists a real lack of desire to put in any meaningful effort. Companies could invest in their new employees and teach them the frameworks they need them to know. Just imagine the long-term benefit of showing employees that you care enough about them professionally to invest in them! Programmers could invest in themselves and learn new skills throughout their career instead of being content to use long-dead tech. Of course, neither side wants to invest any effort. So, companies end up without qualified candidates and programmers never go outside their comfort zone to learn new skills.
Challenge Yourself
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!