10 “Skills” We Look For in a Developer

My first paid gig was at 12 years old programming in ZX Spectrum back in 1982. Before Excel (1987) and Quattro (1988), there was a thing called VisiCalc (1979). From that point on I developed in Basic, VisualBasic, moved to Pascal, C, C++ and a bunch of other languages like Mathematica, SPSS or VHDL.

Fastforwarding to DocDigitizer, we are working to unburden people from repetitive tasks through No-Code Cognitive Data Capture with a mix of dozens of languages and technologies, such as C#, Python mixed with Kafkaa, and so on.

As our development team grows, we ask ourselves what we must look for in new developers. Some traits we prefer are skills, some are behaviors, while others are just … things. As IT careers become more popular, and as parents tell their kids to get computer science degrees, we find ourselves having to choose between many talented potential hires. Here are a few pointers, albeit specific to our organization and focused more on people than on team structure. You may disagree.

You tend to excel in the areas you love. It may sound trivial but it is absolutely true. As a developer, you must love programming. When I was a teenager with no internet in Lisbon, Portugal, we waited patiently for the monthly issue of Byte magazine at the school library. During lunchtime, we read the magazine or went back to our classrooms to continue programming. Were we nerds? Yep. It’s pretty similar to a musician who likes to play a guitar in their free time or a football player who keeps kicking the ball around.

Why is this crucial? Only with passion will you keep pushing the envelope, continue to eagerly learn new concepts, test new ideas, or learn new programming languages and technologies. One red flag is, when talking about free time, a developer never mentions technology or development. It's like a musician saying that outside of their own gigs, they never go to a concert.

I know this may come as a shock, given the myriad of methodologies, platforms, languages, courses, and so on. Again, programming is like playing a musical instrument or a sport; it is an act of pure creation. You may say, “95% of programming is copying pasting code from a Google search.” Even if that was the case,  it’s still an art form. From all the possible outcomes of programming, the developer invents the specific steps that make the world a better place. But like a musician, your code will run in a specific context, and you create, select, and adopt the best approach to run in a specific infrastructure with defined resources. For example, where you may adopt a recursive function because memory is not a problem, you may adopt a non recursive flow in a small IoT device.

I still remember the “religious” wars between C# and Java ecosystems. In fact, they’re not entirely gone. A programming language is simply a tool made by humans to allow others to create something. Trying to enter into such a war is like trying to convince people that an electric guitar is better than an acoustic guitar. A developer must be flexible enough to know more than one language. The programming language they love will evolve and some other new programming language will appear that will be even better. Like a musician, it’s important to learn a lot of them, and learn the approaches that each of them excel at.

We prefer developers who have a background of multiple programming languages and learn how to extract the best of them, and how to cope with their limitations. 

The developer ecosystem is much larger than the syntax and semantics of the programming language. The entire ecosystem also includes the development tools, the libraries, and other developers.

All too often I interview developers who still only use the basic of IDEs, not aware of recent advances in libraries and alike. Back in my day, I had my fair share of sending bugs of Borland 3.1 C++ compiler back to Borland, where the compiler wrongly optimized the Assembly code. When a developer does not take the time to understand every single option of the IDE or Library, their deliverable looks like it was developed by a “wizard.” It’s akin to, in today's gaming scene, when a so-called “professional gamer” does not tweak the game's options or configure their controls properly. Do you really expect a professional to play Counter-Strike: Global Offensive or Fortnite with a Bluetooth mouse?

For example, a developer who is using a database and does not know the exact version of the database may be missing critical performance advancements that the SQL engine offers. And yes, for a backend developer we often ask which exact versions (major and minor) of SQL (or any other database) they're developing for. 98% of candidates don’t have the faintest idea.

How often, when looking at someone's code, does a developer say “This is rubbish, I can do better! I’ll rewrite this code because I don’t understand it.” Is “not understanding” code a good proxy for evaluating code? Does it mean that by not understanding Einstein's Theory of General Relativity, one can disprove the theory?

A good developer must understand their “sandbox.” With current developers rotation, a balance must be found between rewriting everything (and the next guy you’ll rewrite your code also) and not touch critical stuff that should be touched.

From this perspective, the developer has critical powers because they have the agency to decide, line after line, class after class, API after API, where to trust, touch, or refactor. By only adding new lines, even if they are good, and letting bad code remain, you are allowing potential dormant viruses to remain. Having the audacity to correct all past mistakes is a waste of resources and for sure a little arrogant.

During the 5th week at my first job, we were using FTP software for the IP layer in Windows 3.1 (1995). We kept receiving help desk calls that the IP connection had stopped working randomly. We discovered a mitigation path: replace the windows winsock.dll with FTP’s windows.dll. It worked for a while, but sometimes users encountered the same problem. We didn’t know why. Only 2 months later, when I was studying for a Win 95 certification, we discovered  a simple paragraph buried in a 700 pages book: “the first 3 times Windows detects a change in winsock.dll it replaces with the backup copy.”

Writing excellent code is about knowing exactly what you can do with the language. It is the difference between writing so-so English and Nobel prize winning material. A good example is Link or Parallel in .Net. It keeps evolving and it is worthwhile to do more than scratch the surface. Have you ever considered exploring public open source .Net code? You can learn awesome stuff.

There are several common myths about being an excellent developer and not asking for help is one of them. There is nothing wrong with asking for assistance. However, if you ask for help because you are lazy, then it’s merely a waste of resources. Not trying to find a solution and always asking for it is also a waste of time for your colleagues. As a developer, you must understand the importance and impact of your code in a product or service. The objective is to get to the goal as fast as you can with the best quality you can achieve. Ask for pointers, not a solution. Be humble enough when you reach a roadblock to be able to go to your team, forums, or support chats for help.

Code is executed eventually somehow, in a computer or maybe in a cloud (whatever that is), with storage, connected via a network to some other devices that might not be in a cloud. You know that the speed of light is actually limited to about 300km/s, right? Did you know the speed of light in a fiber is half of that? If you are calling an API to a cloud server that is in another continent for populating a dropdown, have you considered building a local cache? How about that app that ran pretty well in dev but exploded when in production and the DBA came asking why someone is trying to run 10,000 SQL/s to get the country’s ISO2 code?

A developer must understand how the code will be executed and what the physical limitations of the infrastructure are. Too often developers live in a bubble, like Alice in Wonderland where everything is allowed, only to see real systems crash at critical times.

Sorry to break it to you, but your code has bugs. We know that and you know that. What we don’t know is what you do after facing that reality. Do you properly code the exceptions? Do you prepare your code to send meaningful logs somewhere? Do you document your code? (and we are not even talking about those variables called X, Y, or AnotherCounter). Do you document the rationale behind some strange stuff in your code so that the next guy has a jump start?

The Art of Debugging is one of the key maneuvers in writing good code. The thing is, debugging currently means a lot more than just debugging code. It means that a developer must understand at least the basics of related disciplines like networking, databases, and infrastructure.

We look for folks who are holistic in this sense, who can pinpoint a problem that may not be a code problem. Back to the example in #8, how about building a local cache but also asking the admin team to gain access to a similar service in your own cloud region?

I’ve left one of the most critical for last. A good developer is like a musician where we must exchange ideas, jam, experiment and find solutions, share and talk about problems, challenges, and strategies with the team. For that, good verbal and writing skills are necessary. Do not underestimate the power of communication at a very low level in programming. Long are the days that “nerd” is pejorative as Wikipedia states: “A nerd is a person seen as overly intellectual, obsessive, introverted or lacking social skills.”

Our definition of nerd is someone who is passionate about technology, solves intractable problems and belongs to a happy group of people who transform the world and love what they do.

Actually, it doesn't matter. Someone who excels in .Net will most probably excel in Java or Python. Imagine a great actor, they can play in any drama, comedy, or action movie. If the potential is there, the rest is just focus and hard work.