Arik Cohen

If you’ve been a programmer for any length of time, you are undoubtedly familiar with the concept of “software bugs”.

There’s nothing quite like a fresh bug report to thoroughly ruin your relaxed morning entrance to the office.

But if bugs are the villains, then where are the heroes?

Turns out they exists, they were just never named. So I decided to name them “unbugs” for now.

Have you ever used a piece of software and found it absolutely delightful? That’s a time when you found an “unbug”.

Have you ever looked at a piece of code that a friend or a colleague of yours wrote and you thought to yourself “that’s some slick-a## code”? That’s another unbug right there.

“Unbugs” are the unsung heroes of our software industry. Unlike bugs, they don’t complain, scream or make trouble. They are soft-spoken and gentle and so very rarely, if ever do they catch our attention.

But I think it’s time to put a big, flashy glowing light on them and give them the overdue praise they deserve.

So next time you encounter an “unbug”, file an unbug report and send it to the programmer responsible. Might make his day a bit nicer.

If someone had asked me “what is the number 1, absolutely most important concept in all of software development?” I would answer it using one word: “abstraction”.

Abstraction is all about reducing an idea to its absolute essence.

Let’s look at an example: take the activity of running. If you take a closer look at what is actually happening in your body while you run, your head would spin: a myriad of muscles are keeping your body balanced, your heart is pumping blood like crazy, your lungs are working full speed to keep your blood oxygenated, your sweat glands are pouring sweat on your skin to keep you cool and on and on.

But to you it’s simply running. Your mind simply abstracted, or removed the non-essential details from this concept of running so you can easily think about it.

Let’s look at another example. Here’s some code:

var splitString = str.split("");
var reverseArray = splitString.reverse();
var joinArray = reverseArray.join("");
return joinArray;

Now let’s add abstraction:

function reverseString (str) {
  var splitString = str.split("");
  var reverseArray = splitString.reverse();
  var joinArray = reverseArray.join("");
  return joinArray;
}

In the first example we have to read every line of code in sequence and keep track of what’s happening in order to understand it. If this was part of a larger piece of code we would potentially have to do that over and over again throughout the lifetime of the software.

In the second example however, we give a name to that piece of code which lets us ignore the internal details and keep the essential concept in mind: reversing a string. Aha!

This idea is so central to computers (and life, really) that when you think about it for a moment you realize that the hardware and software you use every day are composed of “layers” (or abstractions) of software. From silicon to machine code, to assembly code, to the operating system, to your application code, each layer can be easily reasoned about without exploding our heads with details.

Creating clear abstraction in software is the essence of software design. It’s the difference between understandable, easy to maintain software and a nightmare to deal with.

Early on in my programming career, I was very lucky to have had the opportunity to work with an expert programmer who took me under his wing. (I prefer using the word “expert” over the word “senior”, because the word “senior” is too muddied up with vague notions about what it means for someone to be a “senior” programmer).

Being a young programmer and with very little experience under my belt, I didn’t consider my mentor to be particularly exceptional. Sure, he was doing a great job. But having nothing to compare it against, I just figured this is how all programmers perform. Little did I know.

Over the next 12 years I’ve crossed paths with many programmers — some great, some not so much. Nonetheless, having worked with programmers of varying degrees of ability allowed me to put that initial experience into perspective. Moreover, I began noticing certain key characteristics, common to almost all expert programmers I had run into:

Craftsmanship

Expert programmers treat their work like the age-old fine craftsmen: quality is king. While average engineers churn out reams and reams of code, expert programmers write code that reads more like poetry than code. Their code has an actual aesthetic quality to it and they believe that “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”-Antoine de Saint-Exupery

Responsibility

Expert programmers really own their work. Expert programmers don’t wait around for “sprint planning”, to be assigned tasks or for someone else to write “stories” for them. They simply take ownership of the problem and get to work. This also extends to not blindly following rote requirements and just do what their told — thus passing their responsibility elsewhere . Instead, they constantly challenge the status quo in order to get to the bottom of the situation and to deliver the right solution. They believe in giving their customers what they need, not what they think they want.

Expert programmers make mistakes like any other programmers. But rather than blaming the stars, the weather and the dog next door for their faulty code, they get down to business to solve the bug. They do not dismiss bugs as a “one-off glitch” or (god forbid) write workarounds around them. Rather, they find the root cause of the problem and eliminate it.

Agility

Interestingly, and almost counter-intuitively, expert programmers move very quickly from problem to solution. Despite spending more time on properly designing, writing and testing their solution they usually deliver much quicker than the average programmer. This is because expert programmers rarely start from scratch. Their software is typically built in a way that promotes reusability and extensibility.

Another advantage of the Expert programmer is that they recognize that the vast majority of problems were already solved time and again by other programmers. These solutions can often be found in the form of code libraries, write-ups and best practices. While average programmers will try to solve the problem with the tools and knowledge they have, expert programmers will seek other viewpoints, even if it means getting into uncharted waters.

Passion

Expert programmers are some of the most passionate individuals I have ever met. They love what they do and their job seems to me more like play than work. As a result, programming is not something they put aside when their work day is over. They usually spend significant amounts of their free time reading about, practicing and improving their craft. It is this diligence of practice that often has the expert programmer appear as exceptionally gifted. What usually passes as talent is actually consistent study and practice over a long period of time.

Parting Thoughts

If you run into one of these expert programmers, I have but only one piece of advice to give you: “leach” on to them like your life depends on it and learn everything you can learn. No book can replace the one-on-one experience and the gains attendant to apprenticing under an expert programmer.

Also, if you have a related story to share I’d love to hear about it.

Java is unarguably one of the most popular programming languages in the world today. Companies like Google, Amazon and Netflix — to name a few big names — are using Java to build large portions of their infrastructure and backend services. But despite its huge popularity (or perhaps because of it) Java’s reputation among programmers is something of a mixed bag. Some seem to genuinely like it while others hate it.

Personally, as someone who has been using the language for more than a decade professionally, I find it to be an excellent language. No, it isn’t perfect. And the programming world — being young as it is — is still learning from its own mistakes. But all other things being equal I think that Java got a lot more right than wrong.

Following are some of the things I think Java got right:

It’s a productive language

As a programmer I get paid to solve problems. In minimum time and maximum quality. My software is expected to be robust (bug free), performant and maintainable (easily extended). I typically write large, distributed and fairly complex server-side software.

Java is a purely Object Oriented language. To the uninitiated, this means that you design your code around unit of codes called “objects” which loosely resemble real-world object (or concepts). So if you were to write, say, a library management software you’ll most likely have these code objects representing books, members, staff but also more abstract concepts such as genre and loan.

This happens to be a very neat way to organize software (and your thoughts). Instead of thinking about your system as a big line-by-line, step-by-step algorithm, you think of it as a set of interacting objects. If done right, each one of these objects can be reasoned about independently from other objects. Each object can be tested in isolation from others and each one can be extended without necessarily affecting the entire system.

Java did not invent the idea of Object Oriented Programming. In fact OOP dates back to the late 60’s, but the Java language designers did a great job implementing the idea in the language in such a way that it is practical and productive for the programmer.

The Java Virtual Machine

One of Java’s most convenient features is the Java Virtual Machine (or JVM). The JVM essentially acts as the translator between your Java code and the particular operating system that your code is running on. This is the origin of the once-famous Java marketing slogan “write once, run anywhere”. Without the JVM, you’d have to compile your code for every operating system separately. the JVM guarantees that your Java code runs identically on Linux, Mac or Windows.

The Java language designers also envisioned a world where other languages can execute on the JVM besides Java. To that end they’ve specified a low-level language (called “bytecode”) which is the language that Java complies into and the stuff that actually gets executed on the JVM. Today there are dozens of languages targeting the JVM as a result.

Automatic Memory Management

If you ever used a language such as C or C++ then you are intimately familiar with the painstaking effort involved in manually managing memory allocation (and deallocations) in your programs. This is an area, so rife with bugs that the designers of the Java Programming Language decided to do away with it completely. Rather than giving the programmer the opportunity to shoot themselves in the foot they decided to let Java do all the memory management for them — automatically.

In Java, the programmer simply creates whatever objects they need (without explicitly worrying about allocating memory for it) and Java will automatically reclaim that memory once the object is no longer used by the program.

Standing on the shoulders of giants

Java was designed and implemented by some of the brightest people in the Computer Science world. People such a Doug Steele, Joshua Bloch, Mark Reinhold and Brian Goetz are true masters of their craft and are a constant source of inspiration and learning for me. Not just about Java per se, but more importantly, about writing better software in general.

Huge community

As of this writing, according to Wikipedia, there are 9 million Java developers around the world. This is a huge advantage because for just about every problem you run into as a developer there is a high likelihood that someone, somewhere had already solved a variation of this problem or that very same problem. Usually a simple online search will reveal multiple sources that can be used to solve or at the very least approach the problem.

Fantastic frameworks & libraries

Java has an enormous array of frameworks and libraries to choose from. From logging, to web development, to database connectivity, to messaging clients, there’s a library (or several) to help solve just about any problem. A particular favorite of mine is the Spring Framework which had become the defacto framework for any sort of work involving web (HTTP) technologies.

Writing web application using “raw” Java would be a tedious task, to say the least. Moreover, the designers of Spring noticed that many programmers are trying to solve the same (or very similar) problems and each one is solving these problems slightly differently. Spring (and its vast portfolio of sub-projects) are meant to give the programmer a leg-up by giving them a solid set of building blocks to build upon for their projects.

Closing thoughts

There are many fine languages to choose from out there. Java is just one of them. This article is in no way trying to claim that “Java is the best” or that “Java is better than X language”. It is simply meant as an acknowledgement to the fine work that made Java possible.

A relative who is making his first steps into the world of programming recently asked me what is meant by the term “serverless”.

I have to admit that the term is a bit of a misnomer because all applications eventually run on an actual server. But marketing folks and others like the term, so it stuck. It’s a bit like calling credit-card based purchases “moneyless”. You’re still paying your hard-earned money. It’s just that someone is taking care of the logistics of moving the money around for you.

But to actually understand this whole concept of “serverless” we have to step back in time a little bit. And even before we do that, let’s define what is meant by the term “server”.

A “server” is any computer who provides any sort of service to another computer. That’s it. So the computer that is hosting my website is a server because it serves my website to your browser. Likewise, the computer that Google uses to send and receives emails for you is also a server.

So when the internet was making its very first steps it was composed of a handful of giant servers called mainframes. These were located primarily in academic institutions and were used for research as well as for sending messages between each other.

Later on, when the World Wide Web came to being in the early 90’s, many computer hobbyists began connecting up their personal computers to the internet and using them as servers to serve up their personal websites, share files with one another, chat etc.

Soon, companies started realizing the monetary potential of the internet and began creating online stores and other digital assets to promote their products. Each company would buy one or more computers, stick them in a specially designed room called the “server room” which would house all these servers and serve their websites from there to the world.

This was fine for a while but probably somewhere around the smartphone revolution (2009ish) the amount of devices and internet usage really started to take off — vertically. Companies were faced with a whole new breed of problems. First, there was the issue of load. Their servers were getting “hit” a lot more and a lot harder and they needed to deal with that. Second, their websites are becoming more and more crucial to their operation and “being down for maintenance” was no longer a viable option. Third, they were constantly putting down fires caused by malfunctioning hardware.

But at the end of the day, the vast majority of these companies were not in the computer business and could not care less about it. They just want to have their website up and sell their products.

Around that time, a little-known company called Amazon identified this issue and said to these companies: “hey, we know all this server maintenance thing is really hard. So why don’t you let us do it for you? you can rent however many servers you want from us and we’ll charge you by usage.” And many companies did. And the “cloud” (rented servers) was formed.

So companies started shutting down their internal server rooms and switch to the “cloud”. So now instead of going to dell.com, ordering a server, waiting two weeks, installing it in their server room, configuring it etc. they just click on a few buttons on their Amazon cloud console and voila they have a new server ready to go.

This was great for a while but now companies were facing new problems: First, the amount of traffic that was hitting their websites was going up and down throughout the day and so they needed a strategy to turn these servers they were renting, on and off so as to not waste money when the traffic is low and so as to give great experience to all customers when traffic was peaking. Secondly, they needed to monitor all these servers and lastly they needed to make sure that there are servers in different geographical locations around the world in case there is an outage (yes, even Amazon goes down sometimes).

So Amazon folks identified this problem and thought: “what if we tell our customers: hey, don’t worry about servers and scalability and geographic redundancy and monitoring and all that jazz. Just give us your applications and we’ll run them for you. We’ll make sure it’s always on, we’ll automatically add more horsepower as needed, we’ll distribute it across the globe and we’ll take care of monitoring your service for you to make sure it’s always alive. And you’ll pay us based on the amount of resource that your application consumes.”

And “serverless” was born.

When it comes to hiring engineers, it seems to me that most companies subscribe to the “conventional wisdom” of hiring experienced (a.k.a senior) engineers. They want people that “have been there”, “done that” and who can “hit the ground running”.

While there is nothing wrong with hiring senior engineers, the fact remains that there are more job openings than there are senior engineers to fill them. This scarcity leads companies to “cannibalize” on each other’s resources while overlooking a perfectly legitimate pool of high quality resources.

In the past couple of years I was fortunate to work with some really bright “junior” engineers and I decided to sit down and summarize that experience and why I believe that hiring up-and-coming engineers is not only a viable alternative but in fact an advantage.

Experience is overrated

While having extensive experience using the language of choice in your company can be helpful, it represents a fraction of the knowledge required by the engineer to perform their job duties. Any engineer you hire is going to have to spend a fair bit of time understanding your business particularities. No two businesses are the same. Not even within the same industry.

Remember those 12 legacy systems you have that don’t really talk well to each other? Yea, so they’re gonna have to understand how they work. Remember that huge monolith code base that is severely lacking in documentation? Right. So they’re gonna have to spend a fair bit of time wrapping their heads around that one. That’s where the real learning curve is!

What you want is somebody that has problem-solving skills. Someone who is a quick learner. Someone that can get the ball rolling without you having to sit there and hold their hand. Not someone that have some meaningless number of years writing Java code on their resume.

Motivation is underrated

Just like toxic attitude is contagious, the opposite is also true. Junior engineers are typically a very enthusiastic and motivated bunch. They have just discovered the beauty in what many of us take for granted: having the ability to convert your ideas and dreams into real-world, living, breathing computer programs.

This breath of fresh air has an uplifting effect on the moral of the rest of your team and promotes an atmosphere of help where your more senior engineers are suddenly taking on more responsibility by mentoring the more junior engineers. (Assuming your team is not solely composed of egomaniacal a-holes).

Likewise, motivated people will compensate for what they may lack in knowledge with sheer determination in order to achieve results. I’ll hire that kind of person over any senior engineer you put in front of me with indifferent attitude any day.

They are not as “clueless” as you think

In the past year I trained two junior engineers with almost no experience writing professional software. In both cases, I was able to ramp them up within days to start contributing meaningful, production code to our core platform.

My approach was simple but effective: treat them as professional adults, give them just enough to get going on the task at hand and check up on them every now and then to see if they need any help. That’s it.

The “overhead” in training them (which added up to maybe a couple of hours per week) paid itself many times over as these fledgling engineers became more and more productive and were able to tackle bigger and bigger tasks.

This is not an isolated case. In another team within the same company I witnessed similar results: within 3 months of hiring 2 new junior engineers to their team, they have doubled if not tripled their output.

Reciprocity

Decent people feel the urge to reciprocate when treated kindly. This translates to loyalty to your company, evangelizing your business and company culture, referring colleagues to work for you and generally having a fan on your side.

Bottom line

If your company has policies that forbid hiring junior engineers, it may be time to revisit these policies. Be as picky as you like in your hiring process but don’t let past experience be the main drive behind your hiring decisions. Look for bright, promising candidates who can compensate with their attitude for what they lack in experience.

A nice fellow recently asked me for advice on how to get started as a programmer.

This is a surprisingly difficult question to answer and there’s hardly “one good answer”, but I think that there are a few guideposts that can help anyone in their journey.

Purpose

Seems obvious but you’d be surprised at how many people study programming to “know programming” without any clear direction as to what they’re going to do with it.

It’s like spending all your days learning every possible chord for a guitar without ever playing a single song. It’s no fun and you feel like you’re going nowhere.

Decide what it is you want to build. Have a clear image in your mind of what it is you want to make and work backward from there.

For my first project I wanted to create a phone book application. I had no idea on how to do that, but I knew there was a need for it in the place I was working. That gave me a sense of direction and a place to get to.

I went to the store and bought a book that taught me how to build database applications. I read just enough to build the first screen or two. Then I got stuck. I went back to the book and continued reading through it. 30 pages later I had my answer. I used what I learned to build a couple more screens. Then I continued alternating in this fashion. By the time I finished the book I was done with my 3rd project.

Which leads to me the next point:

Commitment

There’s a really interesting paradox of choice today. There are simply too many options on how to get started as a programmer. There’s YouTube videos, online courses, tutorials, projects, bootcamps, books, meetups, colleges and on and on ad nauseam. This can get overwhelming quickly and scare away new programmers.

My suggestion? Pick something that works for you and stick with it to the bitter end.

You can’t attain anything beyond superficial skills by constantly jumping around. Resist the temptation and stick with whatever course of action you picked. When you’re done, you can pick something else.

And finally,

Write a ton of code

Reading books and watching videos alone is not going to make you an expert programmer. To really grok programming you need to write a lot of code. Write code and don’t worry about getting it perfect. A year from now you’re going to look back at that code and feel sick to your stomach. That’s okay, because a year after that, you’re gonna feel the same about the code you wrote the year before. It means you’re getting better.

Happy coding.

Computer scientists that need to write code for a living, constantly straddle the line between the beautiful and neat little world of theory and the somewhat messy, “macgyverish” world of practical software engineering.

In the theory world, cute cuddly objects pass messages of peace and love between each other. They live on a beautiful planet, replete with natural resources.

In the practical world, objects sometimes try to set each other on fire. They drunk drive, and they live in a 100 sq ft apartment with their wive’s mother who moved in after they got married to that hot method from that other project.

But all the same, computer scientists are always trying to bring some of those cute objects back with them from Theory planet whenever they go on a visit.

One time, even I got lucky. A large company I worked for needed a directory system to help customers navigate their city-block-size building. You know those You-Are-Here maps they have in the malls with a red big dot that tells where you are. So like that, but on big digital screens.

Anyhow, long story short the project manager predicted this project will take many weeks to complete due to the perceived complexity involved in routing customers from any point A in the building to any point B.

In fact I thought so myself too. But then I remembered our networking guy saying something about a “shortest path algorithm” a while back. At the time he was trying to explain to me how network packets travel in an efficient manner given several possible paths.

A simple Google search brought back a complete implementation of an algorithm called the Dijkstra’s algorithm. The whole thing, top to bottom must have been 100 lines of code in Java. Very concise.

Since I didn’t know a thing about how it works or what it’s trying to solve I pulled up the Wikipedia article:

Dijkstra’s algorithm is an algorithm for finding the shortest paths between nodes in a graph.

For example, if the nodes of the graph represent cities and edge path costs represent driving distances between pairs of cities connected by a direct road, Dijkstra’s algorithm can be used to find the shortest route between one city and all other cities.

Oh, okay. So all I have to do is model all the points in the building as “nodes”, link them using “edges” and assign a distance to every edge. Then the algorithm can use this information to figure out the shortest path from any point A to any point B. Sounds easy.

I copy pasted the code to my project, fed it a few sample points and tested it on pair of endpoints. It worked.

I tried it on a few more endpoints, added alternative paths for the algorithm to choose from and it worked flawlessly every time.

I deployed the code to our dev environment and showed it to the project manager. He couldn’t believe it. I was showing him a working demo of the product within days of receiving the assignment.

He then proceeded to test it himself. Certain he could find edge cases which would break the algorithm. He even came to me a few times proudly announcing that he found one. But in each and every case we found out that his input was at fault and not the algorithm.

So what’s the moral of the story? Well, for me at least, it was the realization that Computer Science is a useful subject and that it is a distinct activity from software building.  Moreover, it taught me that there are powerful, fundamental principles to programming. And that it’s absolutely worth learning these fundamentals very well, because the time invested in learning them will pay itself back many times over.