I have noticed a growing trend of the hacker mentality, especially among younger, less experienced programmers. What exactly makes one a hacker, and how does it differ from being a software developer?

Learning to program has never been easier. Websites such as Codecademy, Code School andKhan Academy aim to teach programming skills catered to all levels of abilities. It has also never been easier to find work in programming, as the majority of businesses are going digital in order to better promote and sell their products to the masses, creating a huge marketplace demand for qualified software developers. If you’ve ever had a LinkedIn profile and advertised yourself as a Software / Web / Mobile developer, you might have experienced first-hand the forces of the market as recruitment agencies scramble to pitch you to employers that offer “generous remuneration”, “free lunches and Friday beers”, and “pet-friendly workplace” among many other jaw-dropping benefits.

This is of course a flattering gesture for existing software developers. Those aspiring to take up software development jobs may find it a lucrative career choice as a result. As a software developer myself, I’ve had the chance to work closely with other developers, whether or not they are hired through recruitment agencies. No two developers write code the same way, and it is often interesting to compare yourself with other developers who may approach a business problem with solutions different to yours. I have noticed, however, a growing trend of the hacker mentality in software development, especially among younger, less experienced programmers. What exactly makes one a hacker, and how does it differ from being a software developer?


Hackers deliver solutions in the shortest possible timeframe. Developers deliver solutions in the best possible quality.

We often think of a hacker as a basement coder who exploits security flaws in corporations for personal gain, such as money or fame. This is a narrow definition and does not paint the full picture of what a hacker really is. Broadly speaking, a hacker is a problem solver who is focused on devising and implementing solutions to a problem in the most efficient way possible. Hackers are concerned with what to do when faced with a problem, which often involves programming. They then proceed to write code that “just works” to solve that problem, even if that means copy pasting someone else’s code from Stack Overflow. Hackers are not typically concerned about code quality, in fact, it is usually secondary to solving the problem at hand.

Software developers, on the other hand, have a high-level visualisation of the solution that needs to be implemented when faced with a particular problem. Like hackers, they need to understand what needs to be done, but they are also concerned with why and how things are done a particular way. They will often go to great lengths to ensure that the resulting program follows the principles of good software architecture. They are also naturally obsessed with detail. Why is this line of code necessary? Couldn’t these two lines of code be written in one line? Wouldn’t this code break <feature XXX> in <insert some other part of the codebase not touched by the programmer’s change>? These are common questions that one can expect to hear from a software developer when he (or she) looks at a fellow programmer’s code. This pursuit of perfection may seem time consuming and redundant, but it is an essential day-to-day task of a developer and is part of what drives them to produce the best quality software possible. Take for example Linus Torvalds, who is famous for his blunt and confrontative code reviews on the Linux kernel mailing list.


Hackers are coders first. Developers are planners first.

Programmers love to write code, and their first intuition when presented a problem is usually to start coding straight away. As you will see a bit later, this is not always the best approach.

There was a time when the one and only Mark Zuckerberg declared The Hacker Way to be the de facto Facebook approach to developing their products. The Hacker Way slogan — “Move fast and break things” — encourages very rapid development cycle whereby a feature is released as soon as it is available, often without much testing. I was never an advocate of their approach, and it seems Facebook had dropped The Hacker Way in favour of more thorough testing and slower product rollouts which are typical of the more traditional software development process. Perhaps releasing updates at breakneck pace may have caught up to them in the form of increased user dissatisfaction? One can only guess.

All too often I see real-world programmers hired in a rush to help complete projects that are already behind schedule. The intensity of the pressure may force them into writing code before knowing the full extent of the project scope. It may be their natural penchant, or it is perhaps a gesture to show employers that they are working hard to fix issues within the tight deadlines. From my experience, the risks of a rushed hack job far outweigh the benefits, as programmers working in this environment are forced into short-term thinking that makes them cut corners, introduce code smells, deliver partial features and ship programs with defects. These defects manifest themselves when the product has gone live, causing the very same hackers to write even more code to patch the issues.

A good software developer knows to take a step back, research the codebase thoroughly, identify potential problems, ask the relevant questions, and plan his/her solution carefully. Only once they have a solid understanding of the system and a clear path to the solution do they start coding. While this approach may seem counter-intuitive and a significant time investment upfront, often the end result is a project that gets delivered with little to no defect, and high code quality that is pleasant to read and easily understood by your technical team.


Hackers are implementers. Developers are facilitators.

“If it works, it’s perfect.” A lot of hackers swear by this mantra. This thinking is typically adopted in the early stages of project development when the goal is to deliver a working prototype. Hackers normally “wrap up” their work once a solution is known to be working and move on to the next problem set. They are thus able to tackle many problems in a short period of time.

Software developers, on the other hand, understand that the real work begins once a program is made to work. As part of delivering a business requirement, a developer often creates a few “reusable components” that other programmers can utilise. For example, when a developer completes the user account feature of a website, other developers may want to use login/logout portion of that feature. A good software developer will create an abstraction layer or interface that allows other developers to reuse a functionality without having to understand how it is implemented internally, thus saving future development time. If a certain part of the program is difficult to understand, a software developer will leave explanatory comments for future maintainers. If a certain part of the system is best developed using a certain design pattern, a software developer will evaluate several known patterns before choosing one that works best for the given problem. Software developers are facilitators in the sense that on top of delivering solutions, they empower future developers by easing their workload so they could deliver faster and work more efficiently as a team.

As you can see above, hackers approach a problem quite differently to developers. Hackers get the job done fast, but their code tends to become an issue when a project grows in size with more programmers involved. Hackers are typically not interested in how other developers perceive their code, as they are focused on delivering solutions and moving on to the next challenge. This single-mindedness means that hacker codes are typically prone to bugs and difficult to digest, making it costly to maintain in the long run.

Conversely, developers tend to spend more time to finalise their solutions, but they tend to last longer and require minimal changes as time progresses. The reason is that they spend a lot of development effort to “get it right” the first time, delivering near-flawless solution that is also easily extensible by other team members. This makes them very good candidates for building robust, sustainable IT systems. They are also capable of going the extra mile during code reviews by catching bugs early and educating team members into writing good quality code. These attributes make them natural team leaders that can inspire junior programmers and scan new recruits for talent.

So, is it better to be a hacker or a developer? The answer to this question generally depends on the circumstances surrounding your project, but I encourage you to adopt a developer mindset in your day-to-day work, especially if you are serious about your craft. My personal rule of thumb is that if you cannot clearly visualise how you are going to write your code from start to finish, you should research and plan your solution first before you start writing any code. As the age-old saying goes: failing to plan is planning to fail. This is no less true in software development.

One thing to remember is that over the span of your career as a programmer, you will inevitably have to work with other programmers from time to time. This means that there will be opportunities for you to demonstrate your technical and collaboration skills. Good software developers will have no problems working in teams in the best software projects, as they are good at implementing quality solutions and possess excellent skills in communicating their ideas and letting others learn from them. Their contributions are thus invaluable to the technical team, and thus to the business that depends on it.

Arthur is veteran software engineer focusing on DevOps at Industrie IT.

Arthur Rimbun

Author Arthur Rimbun

DevOps Consultant

More posts by Arthur Rimbun

Leave a Reply

All rights reserved IndustrieIT