![](http://steemit.bitcalm.mm.st/posts/always_coding/banner2.jpg)

In the film [Glengarry Glen Ross](http://www.imdb.com/title/tt0104348/), Alec Balwin's character Blake goes on a 7-minute rant on the importance of closing a sale. Three minutes into the rant [he flips over a blackboard and points to the words "always be closing"](https://vimeo.com/mavada/brassballs#t=176s), aggressively repeating the words.

![screenshot of the scene from the film](http://steemit.bitcalm.mm.st/posts/always_coding/always_be_closing_screenshot.png)

This has become a popular meme for programmers, with the word "coding" replacing the word "closing".

But why should you "always be coding"?

# 1. To learn new technologies

Very few professions change as dramatically, and in such a short space of time, as software engineering. Developers who don't go with the flow will be left behind as new graduates, who have studied these technologies, enter the job market.

A great example can be found in databases. For more than twenty years relational databases dominated this space. When the needs of Web 2.0 required better availability and partitioning of data, and faster access to it, NoSQL was born.

NoSQL is a high-valued skill, and whilst relational databases are still important, it's rarely enough on its own.

# 2. To develop a portfolio

Employers wants the best of the best. Traditional avenues for finding Seriously-Good-Programmers™ are fraught with uncertainty: a résumé only provides a glamorised overview of a candidate's experiences; and [technical interview performance are kind of arbitrary](http://blog.interviewing.io/technical-interview-performance-is-kind-of-arbitrary-heres-the-data/).

Recruiters need to see what a candidate can do. Jeff Atwood of [Coding Horror](http://blog.codinghorror.com/) (and a whole bunch more) fame puts it best in his [how to hire a developer](http://blog.codinghorror.com/how-to-hire-a-programmer/) guide:

>Just seeing what kind of work people have done, and what sort of online artifacts they've created, is tremendously helpful in getting a sense of what people do and what they're good (or bad) at.

Your portfolio is a record of the journey you've taken in becoming a programmer and gives recruiters a much better image of what you're capable of.

# 3. To keep skills fresh

When you began your road trip to become a **Rock Star Programmer™** you learned a lot of topics in a short space of time. Many of these topics won't be used on a daily basis when you get your first developer gig, causing the knowledge to deteriorate.

For example, you'll have an idea of how to implement a breadth-first search or how to determine the run-time complexity of an algorithm, but if put on the spot to explain it, or even worse implement it, you'll find it difficult.

Or think of it this way: in football (the English kind) penalties are a relatively small part of the game. Despite this players practice them on a regular basis so that when the skill is called upon it feels natural.

# 4. To improve problem solving skills

At its heart software engineering is about solving problems. It's about using code to serve a need. And because software engineering spans so many different fields it's important to learn how to apply your skills in such contrasting domains.

My first job after graduating from university was on a team developing a document notification system for processing pension applications; in my current job I work on web service that predicts mutations in proteins. This diversity is what makes software engineering so interesting, but it also poses a challenge: we need to learn to apply our skills in unfamiliar domains.

I think Eric Evans describes it most succinctly in his seminal book [Domain-Driven Design](http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215):

>When we set out to write software, we never know enough

The more we practice our art. The more domains we apply our skills to, the more natural it becomes.

# 5. To become an expert at something

Working on adding tools to your software engineer's toolbox gives you the diversity you need in a world where technology changes direction so quickly.

As you grow beyond junior roles to more senior positions, it can be advantageous to specialize in something, and [unless you're Jon Skeet](http://blog.stackoverflow.com/2008/11/stack-overflow-is-you/), you won't be able to specialise in everything.

This could be a particular language like C++ or Rust, or a platform like Android. It could even be something more abstract, like algorithm design or systems architecture. What it should be is something focused and something that you enjoy.

---

Always be coding encapsulates the sentiment that developers should make a concerted effort to grow, to [get better at programming](https://steemit.com/programming/@bitcalm/how-to-get-better-at-programming), increasing their value and improving the quality of software they produce.