DEV Community: Parker Software

Why is on the job programming training so rare?

Parker Software — Mon, 26 Oct 2020 15:45:38 +0000

On the job programming training is sought-after, but seldom offered in any kind of consistent, structurally embedded way.

Market demand for developers is high. And there’s no shortage of budding or would-be developers looking to get a foot on the career ladder. But few programming jobs offer formal, dedicated training and development opportunities.

While this may sound counter-intuitive, there’s actually a reason why systemic on the job training is so rare in the programming field. Here’s a closer look.

Integral learning

First, independent learning is integral to programming. It’s difficult to succeed as a programmer without the drive to self-educate; without unquenchable curiosity on how to solve technical problems.

As a programmer, you never stop learning. There’s always a new language to dive into, a new framework to master. Competence is something that must be energetically maintained.

On the job programming training, then, is something that happens naturally and on an individual level. As a programmer, you’ll learn based on what challenge has surfaced that week, or what new feature request has rolled in, or what legacy codebase needs refactoring.

Learning how to code in a classroom or bootcamp is not quite the same as coding in an office environment. The real world hosts a lot more surprises. (And a lot more headaches.)

So, formal worksheets and carefully planned training sessions don’t always correlate with the ever-changing needs of the business. Instead, your learning will happen organically and altogether more spasmodically.

An egalitarian environment

Next, development jobs are geared towards people who thrive on self-teaching. And that’s due to the egalitarian nature of programming.

There’s no doubt that programming is a highly skilled occupation. But it remains one of the few highly skilled occupations that requires no professional certification.

You don’t need a degree to be a programmer – it’s something you can go away and teach yourself with only a computer and an internet connection. (Provided you have the necessary commitment, of course.)

So, developers who dedicate their free time and energy to constantly grow become the most successful. On a level playing field, your motivation to continually grow your skillset determines how far you climb.

And this creates something of an unwritten programming rule. Namely, developers are often expected to be able to think problems through independently.

Rather than on the job programming training, then, the assumption is that a good developer will be able to problem-solve and self-teach on the job.

A lack of resources

Last, most companies simply aren’t equipped to offer detailed, in-house training when it comes to programming.

True, they might employ a junior developer and pair them with a senior mentor. Other times, the company might reimburse you for a book on a new language, or an online training course, perhaps.

But ultimately, the developer will still have to do much learning by 'doing' in solitude. Very few organisations will have a specialised on the job programming training course in place for developers.

On the job programming training ain’t easy

In development, then, it is not quite so easy as to simply train employees on new skills.

With so much ground to cover, so much changeability, and so much independent learning required, programming doesn’t naturally lend itself to formal in-house training.

Rather, programmers must train themselves, or risk a gradual erosion of skillset value.

Originally published here: https://www.parkersoftware.com/blog/why-is-on-the-job-programming-training-so-rare/

Feature flags: what are they good for?

Parker Software — Fri, 21 Aug 2020 09:58:14 +0000

Feature flags, otherwise known as a ‘feature toggle’ or ‘feature switch’, are a nifty tool that help with feature management. A feature flag grants developers the ability to turn features in their software off or on at will. (That is, without releasing new code.)

With feature flags, you can enable or disable your product’s features any time. Even after you’ve deployed your code.

But why is this so useful? Here, we explore the different uses of feature flags, and why they’re so beneficial in product management.

Good for release management

One use of feature flags is for release management. Such feature flags are sometimes known as release flags or release toggles.

A key benefit of these helpful flags is that they help you keep deployment separate from your rollout. You can add the feature-enabling code to your server, without making it available to users.

So, you can deploy a half-built feature as latent code. Then you can continue to work on it, and turn it on when it’s ready for people to use. Or, you can leave it switched off if you choose to drop that feature.

Plus, feature flags help you reveal new features over time. That is, you can gradually turn on functionality as it becomes available.

Good for allowing permissions

Feature flags are also useful in a permissions context. These feature flags allow you to manage which features are available to any given user.

Permission flags, then, prove instrumental when it comes to managing different delivery models. You can turn features (or even sets of features) off and on based on the usage allowances of any given user. For example, toggling the use of premium features for customers that pay for them. Or revoking access to a feature after the user has hit a cap. Either way, feature flags are great for tightening control.

They’re also handy if you want to restrict the availability of features to your internal teams only. This might be for testing, or it could be to help you manage the program. With permission flags, you can turn these features on for internal use and off for your customers.

Good for operations

Feature flags are equally useful for your operations team. They are a powerful tool for controlling the operational aspects of your system.

For instance, your team can mitigate the risk of outdated or experimental features. If a new feature is posing an unforeseen consequence, operational teams can turn it off. Or, if a feature becomes outdated, feature flags can help you retire it.

In addition, you can minimise change aversion by removing features gradually. (Achieved by toggling small sections of functionality.) Or, if preferred, you can hit the kill switch and remove access to entire features in one go.

Another use of operational feature flags is manual traffic management. So, a customer’s usage spikes or your traffic rises to a point that puts a strain on your systems. You could use operational flags to throttle usage and turn off draining features, to prevent a service outage.

Good for experimenting

Next, feature flags are ideal for experimentation and testing. You can release features to different customers. Then, you can collect data about how they use the new features, which ones are popular and so on.

So, feature flags also offer the benefit of easy A/B testing. With them, you can toggle the features for different groups of users in an experiment. Then, you can collect feedback about the preferred design, function or quality of your software.

With feature flags, you can also allow your users to preview upcoming features. You can then collect feedback to fine-tune new functionality before mass rollout.

That’s what feature flags are good for

Feature flags are an underrated tool. They’re useful in various ways, from managing permissions to facilitating experimentation.

So, are you using feature flags in your code?

Originlly published here: https://www.parkersoftware.com/blog/feature-flags-what-are-they-good-for/

Batman and agile development

Parker Software — Fri, 17 Jul 2020 12:32:28 +0000

There are times when a superhero swooping in to solve our problems would be more than welcome. In agile development, this occurs when there’s too much to do alongside the current sprint.

And this is where Batman comes in. But we don’t mean the caped crusader himself. Rather, a member of your team that fills the Batman role.

Here, we explain what exactly Batman has to do with agile development.

The crime of distraction

A programmer’s work is never done. And that doesn’t change because you’re in a planned sprint. There’s just so much to do. When it comes to agile development, it’s easy for an ongoing iteration to fail simply because there are too many distractions.

It could be an emergency support request, or the discovery of a major bug. Whatever it is, agile teams all too often find their time eaten away by emergencies that occur outside of the scope of the current sprint.

The result of this is a team stretched too thin to achieve the goals of their current sprint. This drags out the time taken to get new features working and new releases ready. Which, of course, means delayed launches and disrupted marketing rollouts.

The hero we need

Batman is all about preparation. He even has contingencies in case anyone in the Justice League becomes a problem. It’s this idea of preparation and organisation that your agile development Batman should embody.

Batman in agile development is a team member that doesn’t work on the iteration with the rest of the team. He or she enables the team to get on with the planned development.

Your agile Batman is the answer to the crime of distraction. They’re responsible for those sudden support problems, the surprise bugs not included in your planned sprint. Your Batman fights off the emergencies that would otherwise distract, hold back and disrupt.

A hero can be anyone

In agile development, any member of your development team — new and old — can fill the Batman role. In general, the Batman role requires a broad knowledge of the organisation and the activities of the team. However, for newer developers, the Batman role offers a great opportunity to learn about the organisation quickly.

The Batman developer might not work with your team during that sprint, but they are still a full member of the team. With each new iteration, you should also choose a new Batman. This allows each developer the opportunity to fill the role of the hero. It also reinforces that Batman is a close member of the team.

This means that, because Batman is a team member, you should plan your sprints minus one developer.

Whatever the team needs me to be

It’s possible, to an extent, to plan for development needs. But you can’t predict when you’ll have a support request, or a bug will pop up, or a server needs immediate attention. So, what happens if none of those things happen?

The point of your Batman developer is that they handle the emergencies. If there are no current emergencies, they’re ready to handle one the moment it appears.

To that end, there’s no point in having Batman complete any work on the sprint. All this does is encourage the team to plan for an extra pair of hands they may not have — potentially causing a sprint to fail.

Instead, your Batman developer can spend their time completing low-priority distractions. For example, clearing technical debt or fixing other bugs.

Optional boy wonder

What if it goes the other way, and Batman gets buried in too many big emergencies or stuck on a particularly tricky problem? Batman is only human, and it can happen, after all.

In the comics, Batman has back up in the form of Robin. So, there’s always the option for your agile development to have a Robin developer too. In agile development, your Robin is a second developer on your team that does work on the planned sprint. However, if Batman finds themselves needing backup, they can call on Robin for support.

Robin drops out of the sprint to assist Batman and re-joins once Batman can go on without him or her. In cases when a less experienced or new developer holds the Batman role, Robin may get called on more. (This presents an excellent opportunity for mentoring.)

Batman and agile development

In the movies, Batman states that anyone can be a hero. Anyone could have been Batman. In your agile development, your entire team has the capacity to be the hero of the sprint. Your very own Batman.

We could all use a hero from time to time. So, who’s ready to step up, and don the (figurative) mask and cape?

Originally published here: https://www.parkersoftware.com/blog/batman-and-agile-development

The benefits of being a boring developer

Parker Software — Fri, 10 Jul 2020 15:16:17 +0000

We’re in the age of rockstar developers and ninja programmers. These extravagant job titles beg the question: what’s wrong with being a normal, boring developer?

Not everyone is going to identify as a ‘rockstar’. No matter how great they are at coding, few developers would really consider their work to be magic-wielding wizardry. And not every coder needs their role romanticising with grandiose descriptions.

In the world of development, there’s a lot to be said for being content without the fancy title. But what are the benefits of being a developer, sans ‘rockstar’ attributes?

The labels

A boring developer is one that avoids the fancy titles. Instead, boring developers are those happy to just be developers. They aren’t rockstars, ninjas or wizards. Nor do they see themselves as gurus, geniuses or heroes. They certainly aren’t mythical ‘unicorns’.

When we hear these flashy job titles, distinct images form in our minds. Rockstar developers are the egotistical team members that work at night, to the sound of cheering crowds. Programming ninjas stealthily defeat software bugs with their advanced fighting skills. Tech support wizards fix problems with magic and spell casting.

It’s fun, fanciful and entirely unrealistic.

Step out of the spotlight

With a flashy title comes a metaphorical spotlight on the developer and their work. Rockstars are always in the spotlight. For developers, this means their work is always expected to be at performance level. There’s more pressure and less room for mistakes.

A boring developer, meanwhile, is human. They aren’t mythical, and they aren’t asking for a spotlight all the time. This means they have room to grow and learn – and make mistakes – without being under severe scrutiny.

Flashy job titles put developers in the spotlight, but also hide the hard work behind their achievements and project progress. Their ability to fix bugs or to write high-quality code is explained away as ‘magic’. So, plugging a developer’s skill via a sensational job title only serves to obscure it.

In contrast, a standard developer’s work isn’t hidden behind titles. It is the hard work that goes behind quality code that shines – not a shiny label.

Have a team, not a solitary hero

One of the key elements of the flashy-titled developer (specifically the rockstar) is that it suggests a high level of ego. Egotistical developers are over-confident in what they can do, and they don’t need help doing it.

Too much ego can alienate colleagues and disrupt workflows. It makes collaboration difficult, which then impacts productivity. The lone tech genius is a myth — developers need to be team players.

A boring developer doesn’t exude ego. Instead, they have a better emphasis on soft skills. They’re willing to learn, accept mistakes and support their team members.

This kind of humility has a key role in development. The field, after all, is a role in which everyone is always learning. New ideas, ways of thinking and innovative solutions can come from anywhere. (As can mistakes.)

Have a clear path, not a maze of shadows

A boring developer also has a clearer view of their career progression. It’s impossible to tell who is the most senior out of a ninja, a rockstar, and a wizard. And even if you know the answer for one company, it might be different in another.

A boring developer, meanwhile, is more likely to have a title such as junior developer, developer, senior developer and so on. Here, it’s much easier to tell when you’ve received a promotion, or if changing to that new job is a demotion. In other words, it’s clear where you stand in the company and what the next step up is.

Plus, non-fanciful job titles (like those of the boring developer) are likely to look better on your CV or resume. ‘Senior developer’ is a more solid indication of experience and skill than ‘coding ninja’, after all.

Enjoy the job, not the title

There’s a lot going for the boring developer. There’s less pressure on perfection, and more room for growth, teamwork and productivity. A boring developer is a good developer. They work with their team, they’re humble, and they enjoy the job for what it is.

So, leave the ‘rockstar’ title to the actual rockstars, and own the fact that you’re an awesome, boring developer. When you have a passion for the job, why would you want to be titled as anything else?

Originally published here: https://www.parkersoftware.com/blog/the-benefits-of-being-a-boring-developer/

Should you hire a lazy developer?

Parker Software — Fri, 26 Jun 2020 13:20:18 +0000

Laziness isn’t typically a trait you’d see listed in a developer job specification. Nor is it a quality that many programmers would list in their CV. But that doesn’t necessarily mean that laziness is a negative characteristic in a developer.

In fact, laziness can be beneficial to a career in coding. We’ve all heard the Bill Gates quote: “I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.” And according to one maxim, efficiency is just intelligent laziness.

But is that true, or just wishful thinking? We give our two cents on the virtues of a lazy developer.

Laziness and the Pareto principle

Laziness is defined as an all-around negative trait. It’s viewed as being related to one of the seven deadly sins: ‘sloth’. It suggests a lack of motivation, a lack of productivity and a shiftless attitude. So how could a lazy developer possibly optimise anything?

It all starts with the Pareto principle. The Pareto principle suggests that out of everything you do during the day, only 20% matters. Yet this 20% of your time accounts for as much as 80% of your results.

The numbers may be scary, but they suggest that a lazy approach could be wise. A lazy developer, supposedly, would be one that could better identify and optimise the 20% of tasks that produce results.

‘Do this well, and you will enjoy the world of productive laziness’ – Peter Taylor

Types of laziness

‘Productive laziness’ is the crux of the matter. There are different categories of laziness, and hiring someone with the right type could optimise the time and tasks of your whole workforce. The wrong type, however, is a costly bad hire.

You don’t want ‘idle laziness’. The ‘no-motivation-to-do-anything-ever laziness’. Hiring a sluggish developer won’t get you very far, and isn’t advisable.

But that wasn’t the type of laziness Bill Gates was referring to. The right kind of laziness, as many smart developers will know, is more resourceful than work-shy. A ‘good’ lazy developer will know that laziness doesn’t mean doing the job poorly. It means doing the job the best way first, so that they don’t have to go back to it later.

‘Do it right, do it once. That’s the lazy option.’ – Moray Taylor

Make the machine do it

In essence, the idea behind a productively lazy developer is one of efficiency. Lazy developers will only focus on tasks that are important, rather than robotically wading through a to-do list. They’ll automate anything that can be automated.

This means that a productively lazy developer can optimise not only their own workflows, but also the workflows of others. They can identify new areas that would benefit from automation, and streamline their workloads to only include the important jobs.

No one like complex tasks. Equally, no one likes complex software, or complex code. All of this can be avoided by finding the easiest, most efficient method for completing any one task. A lazy developer is great at avoiding complexity, as they can be counted on to find the simplest way of doing something.

And the best part of this is that once the easiest method has been identified, other members of your team are able to use it as well. Laziness, despite all its negative connotations, can be quite the productivity boon.

Most important?

When it comes to laziness and hiring, it’s not so much that you should go out of your way to employ a lazy developer. Rather, you needn’t actively avoid laziness as a trait in prospective new hires.

Laziness can work well, but it’s not the definitive trait of a good programmer. So instead of worrying about finding the perfectly lazy developer, look for other, more important traits, such as:

Positive attitude

Positivity breeds a good work atmosphere, a willingness to learn, and confidence in the team and its output. Don’t let a negativity virus corrupt your dev team.

Adaptability and problem solving

In programming, fixing problems is a large part of the daily work. The last thing you need is a hostile employee with a closed, ‘can’t-do’ approach to development.

Teamwork

Development is a team job, and all new team members must be able to integrate well. They could be the prime lazy developer, but they won’t inspire productivity if their lack of teamwork causes a system error.

If your new hire happens to hold the quality of ‘productive laziness’ on top of these traits, great. Just see it as a bonus, not a prerequisite.

Now loading, please wait…

Having the coveted lazy developer can improve office workflows, unlock new efficiencies, and decrease burnout of team members. And they can make great team leaders, after all, it’s the second mouse that gets the cheese.

But they can be tricky to find. A developer that’s lazy in the wrong ways can be just as negative as any other bad hire, and gives the rest a bad name.

So, should you hire a lazy developer? Rulers of effective time management, masters of avoiding ‘busywork’; productively lazy developers are lauded for prioritising and cutting out the unimportant. We’d say that makes for a smart hire.

Originally posted here: https://www.parkersoftware.com/blog/hire-lazy-developer/

The ‘done is better than perfect’ approach to programming

Parker Software — Fri, 19 Jun 2020 09:02:06 +0000

When you’ve developed a working product, it’s normal to take pride in its performance— you’ve worked hard on it. It’s normal to want to hold off on release until it’s got this feature, or that’s been tweaked, or it’s gone through yet another round of testing. In short, it’s perfectly normal to pursue perfection.

It is notoriously hard to declare a software product, project, or even a single feature ‘finished’. There’s always something else that could be finetuned, or added, or upgraded. This makes it incredibly difficult to take the leap to release.

In today’s competitive market, though, can you afford to release your product before it’s perfect? Well, the ‘done is better than perfect’ approach suggests that you can’t afford not to. Perfectionist programmer or not, here’s why you should consider the ‘done is better than perfect’ approach.

Done is better than perfect

‘Done is better than perfect’ is a maxim made popular by Facebook COO Sheryl Sandberg. In her book, she refers to the motto as a reminder to let go of impossible standards. She writes that: “Aiming for perfection causes frustration at best and paralysis at worst.”

The concept is not so very different in a coding context. The ‘done is better than perfect’ approach to programming is the idea that a released software product is better than an unreleased product. It focuses on completing a product and having the courage to share it, rather than getting lost in minute details and endless iterations.

The ‘done is better than perfect’ approach, then, is a mindset that challenges perfectionism. It drives us to recognise when our software is good enough, and it pushes us to get each new project ‘out there’. When you’re not busy agonising over intricacies, you can get busy building a customer base and solving the core pains you set out to solve.

That doesn’t mean to say that the ‘done is better than perfect’ approach equates to complacency. It’s not a reason or excuse to release a bad product. The software you release should be able to solve the pain points that it’s designed to answer. It needs to be a good product, it just doesn’t need to be perfect. After all, is there ever any such thing as a ‘perfect’ product?

Perfectionism pitfalls

Without adopting the ‘done is better than perfect’ mindset, you can easily fall foul of perfectionism. And unfortunately, perfectionism is an affliction that comes with more than a few major downsides for your software and your business.

For a start, ‘perfect’ simply takes too long to develop, meaning that it could end up never being released. There will always be something else to tweak. Plus, with technology advancements moving so quickly, pushing for perfection can often leave you working on outdated software and continually playing catch up.

Striving for perfect sets an unattainable goal, based on the need for your product to be liked. It makes sense, on the one hand. After all, you want your customers to love your product, and it can be hard to see that they would do that unless it’s perfect. But perfect is subjective. It’s difficult to align your view of ‘perfect’ with a customer’s perspective, and even more difficult on a granular user by user level. No two users will have the same view on what precisely makes for perfect.

Perfectionism also means you run the risk of software plagued with feature creep. With every new capability that you add in your quest to make that elusive ‘perfect’ product, the core function of your software becomes more crowded and buried. You end up with a mess of functionality that brings no long-term value or competitive edge to your product.

It’s also worth remembering that having a perfect product isn’t the only thing that guarantees success. Does your product efficiently solve a problem? Is there a viable need for it in the market? Key questions such as these are more important than striving for perfection.

Why done is better than perfect

Adopting the ‘done is better than perfect’ approach means that you can get your product out there. When you release your ‘good enough’ product, you start building your customer base, generating a return from all your hard work and efforts.

Along the way, you learn more about the market that your software appeals to. You create the opportunity to collect feedback. In all likelihood, you could discover that the ‘perfect’ you were originally striving for was the wrong one anyway. You might even attract an unexpected audience, or uncover unexpected popularity in certain features or functionality.

A released product means that you now have something to build on. As the saying goes, ‘perfect is the enemy of good’. A supposedly ‘perfect’ software product, once released, won’t lend itself to being improved. A ‘good enough’ product, however, motivates us to improve on it. It lends itself to upgrades, to new tech, to innovation – instead of being a finished product aging into obscurity.

Your products are only ever drafts

The ‘done is better than perfect’ approach to programming is a mindset that reminds us that the products, software and services we release are drafts of the next one. Instead of trying to release the ultimate product in one go, we can release something that’s good enough, and build on it, update it and improve it as we go.

There is nothing wrong with taking pride in your product. Equally, there is never an excuse to ship shoddy, substandard code that you will have to re-do all over again. This is not what the ‘done is better than perfect’ approach is about.

It’s about recognising when your product is good enough. At some point, you have to be able to acknowledge that a product may not quite be absolutely, unequivocally and breathtakingly ‘perfect’ – but that it’s still pretty darn good.

Originally published here: https://www.parkersoftware.com/blog/the-done-is-better-than-perfect-approach-to-programming/

Is programming art?

Parker Software — Fri, 12 Jun 2020 11:30:16 +0000

“You might not think that programmers are artists, but programming is an extremely creative profession. It’s logic-based creativity.” – John Romero

Is programming art? Are those structured, complex blocks of code a stream of creativity that we wouldn’t necessarily recognise as such?

Typically, art is a piece of work that is open to interpretation. It can mean different things to different people; take on a unique significance for every individual subject. But programming is altogether more logical. A computer understands code logically; it can only interpret it in a single way – not based on its experiences or feelings.

So, does this mean that programming and art are distinct, dissimilar disciplines that simply do not overlap? Well, not quite.

Art vs science

Traditionally, programming has been viewed as a science. After all, it is rooted in engineering and computer science. It requires formal reasoning and a methodical process to program successfully. This, then, is why many would never perceive programming as ‘art’. It is a science – knowledge that has been logically arranged and systematised to create accepted ‘laws’.

Art, meanwhile, is not governed by law or logic. When we think of art, it typically creates connotations of the fine arts – painting and sculpture and suchlike. We would generally connect art to visual work created primarily for aesthetic and intellectual enjoyment. (Very) broadly speaking, fine art exists to be appreciated rather than to be put into functional use.

With these commonplace perceptions in mind, it is easy to see why so many would instantly leap to no if questioned, ‘Is programming art?’ The two are as different as a motor and a mosaic.

False dichotomies

So, it’s easy enough to understand how the general perceptions of programming and art have formed. Nonetheless, setting up logical disciplines like programming as an antithesis to art is deeply flawed.

Asking ‘Is programming art or science?’ is like asking ‘Are burgers bun or patty?’ It’s an entirely unnecessary (and rather absurd) distinction that embeds a false dichotomy. Work needn’t be art or science; the two can, and commonly do, overlap. And for many, programming is one such logical field that overlaps into artistry.

Delving deeper

We know the typical connotations of art. But what does the dictionary have to say? There are two main definitions: art as creation and the expression of imagination, and art as skilled craftsmanship. While programming clearly applies to the latter, some don’t recognise its relation to the former.

That, unfortunately, would be short-sighted. Programming is a deep and multi-faceted discipline; one that shares a blend of aspects from science, engineering, and art alike. Yes, programming will always be a logical process, and yes, code will always be framed within a systematic pattern. But that still leaves ample room for creativity.

So, before you ask, ‘Is programming art?’, you need to delve a little deeper into the highly inventive process of writing code.

Logic-based creativity

A programmer starts in the same place as a poet, or a composer, or a painter. That is, they start with nothing and pull something into existence, using their skill and creativity.

And, as with art, there is no single, correct way to program. It’s down to the developer, their brain, and their imagination. The scope of what can be created with code is vast, and it’s all down to the developer to design and architect.

Like creating a symphony, or a literary saga, there are endless options to carry the endeavour from conception to completion successfully. Each programmer will have their own approach; will bring their own unique style to the challenge.

Indeed, a good developer will have a certain ‘feel’ for programming beauty. They will strive to create code that is elegant and aesthetically pleasing. So, programming isn’t just typing logical rules into a screen. Rather, it’s an intersection of logic, individuality, and artistry.

Is programming art?

So, is programming art? Ask anyone who has coded their own program, or chipped away at a software product to make it run smoother and quicker with cleaner code.

Firstly and most obviously, programming is art in a skilled craft sense. Programming can also be used to create art; with code as a resource to create a beautiful end product. But beyond that, on a deeper level, programming is often art as a form.

Programming can be aesthetically beautiful. It is imagination and ingenuity manifest; pure creation branded with each developer’s own individual style. If that’s not art, then what is?

Originally published here: https://www.parkersoftware.com/blog/is-programming-art/