Today’s overwhelming and unlimited access to information, in the broadest sense, courtesy of the Internet, often leaves us unable to isolate the noise. There is a lot of it. Should I learn X, or Y? Or is Z more worth it to spend time on, since *insert group of people* have been using that?
Up-front - I’m not a dev. I’m a tech geek, audiophile, and the Community Manager for Telepat North. I get to spend my days talking with some smart, talented, and amazing developers from around the world, so I have a decent idea of what our most successful members spend time learning, what are best practices in their minds, and how they got to where they are now.
And while there's tons of advice out there to help you increase your coding skills, building a career in tech is not all about being a great programmer. In this article, I'll go into four non-coding, skill-building activities that recurrently pop up in conversations with the best developers.
I’m hoping to provide you with a useful read, minus the noise.
I love using worn-out quotes:
“After a certain high level of technical skill is achieved, science and art tend to coalesce in esthetics, plasticity, and form. The greatest scientists are artists as well.”
I leave it to you to figure out who said it.
Having (or finding) a creative outlet appears to help a lot. For me, it has always been music, so I can share with you a few interesting thoughts - I’m sure it translates into the other arts as well.
The interesting thing is - musicians and devs share some very relevant skills related to the general quality, and output of their work. The musicians’ attention to detail, the need to perfect segments, analytical, logical, and reasoning skills, the tendency to be methodical in one’s work - sound familiar, dev?
The key thing here is, I believe, the mix of analytical and creative that improves work output, its quality, and overall productivity.
“To work on specific aspects of a composition requires the composer to hold the remainder of the musical structure in their mind. Similarly, until there is a working model, there is no ‘software’ aside from the vision and intention of the designer. The final result must be held in mind by the architect of the project, while being able to work on smaller, discrete portions of the project.”
says Alex Jacobs in his wonderful article.
Not as fun, but as it is in many other domains of life, it’s useful to learn to play their game.
Quite uncomplicated - a simple google search will feed you dozens of lists with concrete questions you’ll likely be asked if you find yourself on a job interview for a dev or a similar position.
Practicing this is also a useful tool for reflecting upon your career and its events in the past, your most significant professional achievements, and how they’ve impacted you and your knowledge. Shout out to the self-taught devs out there - don’t forget where you’ve started.
This practice is also something that helps you create your story - and it’s good to know how to tell it well. Turning a series of answers to interview questions into a well-constructed story is the key thought here.
“When introducing yourself, you aim to convey an exhaustive, confident and purposeful story about who you are — not only what you’ve done, but also why you did it, what intimate belief system is driving your actions, what your strengths and weaknesses are, where you plan to go and how you’re working towards getting there. Plus, you’d like to impress your teammates and be memorable.”
- Gabi Dobocan
A well-kept GitHub profile can be a dev’s “passport”, per se. It shows what you do, and insight into how often, and how well you do it. It can also show what others think of your work.
For example - making sure your projects have a well-written README.
Contribution to open-source projects is another valuable metric of a dev’s skills, quality, and scope of work. We encourage our members to always have one or more public, open-source projects featured on their GitHub profile, to showcase their abilities and stand out from the crowd.
Take a look at this:
We’re real preachers of remote work, so pardon our focus on devs working in distributed teams on this one.
I’m sure devs (and other professions) working remotely have experienced this manner of communication. It can leave you feeling unsure of a task you accomplished, the quality of it, or in general communication - asking for help or thoughts on something.
As the team at Doist puts it: “When communicating asynchronously, keep conversations positive, concise and constructive.”
With remote work, keeping track of work progress is sometimes difficult. A team that does daily standups is way more likely to be productive, and to accomplish more work, in a shorter amount of time - with less stress involved.
I hope you’ve enjoyed reading this piece, and that it impacts you in a very positive way directly, or at least, provokes thought about the matter.