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!
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!
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.
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.
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.
python -m SimpleHTTPServer 8080
This will start up a simple HTTP server running on port 8080. Now, point your web browser to localhost:8080 and you can see your web page! Nothing could be simpler for quick testing of web pages or websites!
Day after day, I receive calls from thieves in India. For several months, they said they were with Microsoft and that my computer had a virus that they wanted to help me fix. Now, they claim to be with a credit card company wanting to lower my interest rate. What’s sad is that people fall for these tricks all the time. Often, the elderly are the most vulnerable – not only because they tend to have a fixed income, but because they are also more easily confused and duped. Because of this, I have made it my civic duty to waste as much time as possible on the phone with the scammers. After all, the more time they waste talking to me, the less time they have to scam an elderly grandmother.
Just a few days ago, I received two calls in a single afternoon from hackers – and I took them both for a ride. When they asked for a credit card number, I gave them one of the test credit numbers typically used by developers for application testing – just google ‘test credit card numbers’ for a list. They asked for a bank name, I said Wells Fargo. They asked for birthday, last four of SSN, and other information. I provided false – but believable – answers. Then, after providing the information, they asked me to stay on hold while they verified my data. After another minute or so, the scammer got back on the phone: “We contacted your bank and found out that you are an *********” and hung up on me. Few things are quite as fun as having a scammer call you names or swear at you because you wasted their time!
It’s a new year, and new years mean new challenges. And how can those challenges be faced? By staying up-to-date with technologies and ensuring you have the skills to turn those challenges into opportunities. But there are so many technologies out there, which ones do you learn? I have selected 5 technologies that I think everyone should learn in 2018. These are not necessarily new technologies. In fact, most of technologies listed have been around for awhile and I believe developers can no longer afford to ignore them.
For the last decade, virtual machines have been used to startup new servers. This work great, but is very wasteful of resources. Not only that, it’s very time consuming to both setup and configure. Docker is much simpler and less resource intensive. Want an Apache server, or a MySQL database? Start a Docker instance with that service. Need to experiment with nginx for a new project? Spawn a Docker server to tinker with your new technology. With thousands of images for a sorts of services, it’s likely that you can find what you need. I run my Jenkins and Artifactory services using Docker – it took minutes to setup and has been running for a year or more. There is simply no faster way to setup servers than using Docker.
This one is a bit more speculation the the other technologies on my list. However, since it’s supported by Android, I expect to see it grow in popularity this year with the possibility of overtaking Java in popularity for native Android development at some point in the future. The Android Developer page for Kotlin lists a variety of reasons to switch to Kotlin – including safer code, concise data classes and lambda expressions, default and named arguments (something very popular in a variety of other languages), as well as being fully interoperable with Java. Numerous JVM languages, such as Groovy and Scala, have failed to gain wide-spread usage, but Google’s support for Kotlin code in Android may just change the game.
Linux is anything but new. In fact, it’s been around for decades now. However, it’s sad to see how many people in the tech world are still uncomfortable with the Linux command line. With all the technologies available today that use Linux, it’s time to learn it now! What are those technologies? Docker, Raspberry Pi, AWS, Google Cloud, and Android, all use Linux. Mac OSX has, in large part, become amazingly popular with Linux-savy developers because it uses BSD (A Linux variant) under the hood. Countless other technologies run on Linux or simply run better on Linux. For example, setting up a LAMP stack, running Python, or setting up Node is a breeze in Linux – but can be far more painful on Windows. Connectivity tools such as SSH and SCP run natively too – making deployment and configuration of servers and services easier. If you’re not familiar with Linux, you’re probably working too hard to get your solutions working on Windows.
After just enumerating the benefits of Linux, it may be odd to see a Windows technology on the list. However, The .NET Core framework runs on non-windows machines – and that’s exactly why it’s great! Microsoft’s Entity Framework and their MVC implementation both make for greatly streamlined web development. Running it on a Linux server is icing on the cake. I expect to see growth in .NET Core this year as developers exploit the simplicity of .NET development with the control and deployment power of Linux and Docker servers.
As per Kernighan’s law: “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
Brian Kernighan, the author of the above law, is among the most famous of all computer scientists. He, along with Dennis Ritchie, authored “The C Programming Language”, one of the most well known of all computer programming books. As such, Brian Kernighan’s ideas carry a lot of weight.
Kernighan’s law sounds simple, but it carries a profound truth – that clever code is bad code. When I was a younger programmer, I thought writing clever code was a great idea. I loved writing code that made me appear to be a wizard of coding. Of course, when you write complex code, you realize the first time you try to fix a bug that the code isn’t maintainable. Now, after 20 years of programming, I aim to write simple code – the simpler the better. I want any programmer – today or in a decade – to be able to look at my code and figure it out without any effort. Simple code is maintainable code.
Do you write simple code? Do you hire programmers that write simple code? More importantly, when you hire contractors do they write simple code? Contractors are notorious for writing ‘clever’ code so that you have to keep them onboard long-term to maintain the code they wrote. For a business, this is a huge – and costly – mistake! Clever code will cost you far more than you think over the lifetime of an application!
One of my hobbies is game development. I have been tinkering with Unity for several years now; and I’ve also experimented with Java, Android, C++, and a few other platforms. Unity is, without a doubt, my favorite. The ease of developing 3D games coupled with their outstanding framework makes it an easy platform for developing games. So, when I was asked to help teach a Unity game development class at the high school a few years back, I was excited and gladly took the opportunity. I teach C# scripting to the students every Friday, and it’s great fun.
This last week, I was going over some simple code on creating projectiles and applying the scripts for their movement and destruction. I had started a project a few weeks before, and most of my code was there. However, when I went to continue the project I found that my code was no longer on the computer. Given that the class is only 50 minutes long, this was a real showstopper. I frantically tried to recreate the project I had before and get it to a point where I could continue with my lesson. Unfortunately, circumstances worked against me and my presentation was less than stellar. This experience reinforced two important lessons from computer programming that I will be sharing with the class next week.
First, I have been busy the last few months with my own business and have not been doing as much game development as I would like. This kept me from being on top of my game at class. I made some noob mistakes, and was unable to perform at my peak since my skills were a little rusty from months of under usage. In the tech world today, this is easy to have happen. The world of software development has so many tools, frameworks, languages, and platforms. Developers are increasingly expected to know countless technologies, and it’s almost impossible to be an expert in them all. For example, I have written plenty of Python code over the years, but I still have to pull up my sample code when I need a new script. Why? Because I don’t use python on a daily basis and I quickly get rusty. To stay up-to-date on skills requires constant effort.
Second, rushing to complete something will cause errors. This is as true in software as it is in any other endeavor in life. As I rushed to complete my code by the end of class, I caused more errors. And, in the end, nothing worked the way I wanted. Had I slowed down, I would have been better able to ensure that what I was doing worked the way I wanted. However, the imposed deadline made me work without paying attention to the details. This happens in real world projects too. Unrealistic deadlines force programmers to pound out code without paying attention to the details. Errors are made, code is left undocumented, test cases are not written. Then, when the code is released, it doesn’t work as desired. Of course, deadlines are a part of the real world. But if we are rushed to meet unrealistic deadlines, we can be certain that the result will be less than desirable.
In the end, this experience shows some very real truths about software development. Much like the story of the tortoise and the hare, we see that slow and steady wins the race. We have to constantly reinforce the skills we want to use, we can’t let them get rusty. And, we need to take our time to ensure that the code we produce meets more than just timelines – it must be developed so that it is solid and stable.