So it's 2 AM now.
My FitBit is complaining that I'm not getting enough sleep, but my mind is telling me there's a problem to be solved.
The Mexican stand-off started at about 1AM until I eventually gave up, so here I am
Yippeeee-skippeeeee!!!
Anyhoo, what's so important that you need to face the winter cold at 2AM?
Well, over the last few days I've been battling head-on with an interesting conundrum of our industry (especially here in the good ol' RSA):
- There is more than enough work to be done, often leading to projects that are sitting on the back-burner because nobody is available to do it
- There are tons of people looking for an opportunity to join a project team and build cool stuff.
Not so fast! There's a barrier between the two problems that make them incompatible:
Skills
The skills problem plays the role of the Berlin Wall in my world, because even though there may be countless people available (and yearning) to join cool projects, if they don't have the skills needed by the project, it ain't gonna work.
So we have a problem. And, of course, there are many ways to skin the cat from the company's side of the fence.
But this post is about what an individual software developer can do to improve his/her own life by understanding this problem and leveraging it. In particular, it is focussed on developers who may be wondering why they are struggling to get the opportunities to do the cool things that they want to do.
You may be asking yourself:
"Why am I constantly being asked to do mundane things on the project?"
or
"Why are my job applications constantly getting rejected?"
Of course, I don't have all the answers, but below I'm expanding on a number of steps that I feel each developer should take on the road to becoming a master.
Step 1: Understand that job roles are irrelevant
Our industry is filled with job titles like:- Software Developer
- Full-stack developer
- Front-end Developer
- Back-End Developer
- Business Analyst
- Technical Architect
- Enterprise Architect
- Test Analyst
- Scrum Master
- ...
A Software Developer who is not skilled at writing specification documents is never going to be able to lead teams who create magic. You're type-casting yourself into a corner.
An Architect who just draws diagrams with blocks and lines, but never opens an IDE is never going to be able to make well-informed architectural decisions. You're type-casting yourself into a corner.
A BA who doesn't actively write code on the project is never going to be able to compile requirements that lead to elegant solutions and expose previously unknown opportunities.
Let me say it again, you're type-casting yourself into a corner.
To become a master you must have a firm grip on the skills in each of these fields. Talk to your colleagues. Read the books that they read. Actively engage with the work they deliver.
Step 2: Get a better understanding of expectations
When you're on a project, your team members expect you to deliver. And with the rising popularity of agile methods, the iterations for delivery are getting shorter and shorter.If you are given a specific task by a senior person on your team, make sure you understand what the delivery timeline expectations are.
In practice we generally work on 2 week sprints. During that time functionality needs to be fully understood, implemented, tested, deployed and then demonstrated to the customer. That means that any given task on a project is generally expected to be complete within 1-2 days.
In addition to understanding the delivery timelines, make an effort to understand what actually needs to be delivered. Always ask yourself the question: "How will I know I'm done with this task?". If the answer is "When XYZ reviews it and approves", then you don't actually understand the expectation.
If it's unclear, talk to people, get clarity, make it happen.
Step 3: Read
I shouldn't need to explain why reading is important, but let me help out by explaining what you should be reading.The technical book suppliers (Packt, Manning, etc) all have regular specials and even general subscriptions that allow you to read any technical book available.
As far as possible, try to read at least one technical book every two weeks. And when I say "read", I mean cover to cover.
Yes, you may think that while reading Claus Ibsen's book on Camel, you should try to quickly distill the most important facts so you can get back to your IDE and code - But that is a mistake.
Think of it like this: Claus Ibsen is a globally renowned software developer. Surely, between the code examples there are tons of fundamental explanations that will help you become a better overall developer.
If you read books from cover to cover you join the author on the journey, you properly engage with the content and you become a better developer overall.
Don't skimp!
Step 4: Subscribe to an online learning platform
Don't wait for your company to give you a subscription to Udemy or Coursera or CodeAcademy, or whatever.Take your own career seriously. Get your own subscription and start learning. Select a platform that works for you, but try to pick one that gives PDF certificates of completed courses.
Not only will your skills improve, but if you go to your boss/architect/project manager every two weeks showing the next course you completed you will soon be given the opportunities you've always dreamed of.
Step 5: Exercise
Write code every single day. Get a GitHub account where you can tinker on non-work-related projects or utility libraries that you regularly use.Often times there might not be sufficient time to build whole things, and for those days you should keep up your score on platforms like CodeWars and HackerRank.
Step 6: Commit and Deliver
This is probably the most important step in the process. Your team members (not just your boss) can easily identify which team members are committed to the success of the project.Every project has busy times and then crazy times. When the crazy times come, you need to step up and deliver on your commitments. And beyond your commitments, you must be on board with the team's commitments.
If your team members are staying late to ensure a demo is ready for the next day DO NOT WAIT UNTIL THEY ASK YOU TO STAY.
I cannot stress this enough: Immediately volunteer to stay and help, even if the issue isn't related to your work.
If you prove to your team members that you can be counted on when the chips are down, they will do the same for you. People remember stuff.
Closing remarks
We live in a free world, but freedom doesn't mean everything is free. The only way that you'll make your dreams come true is if you grab hold of the steering wheel and make things happen.And in the words of Forest Gump: "That's all I got to say about that"
Copyright Note: The image at the top of this post is the iconic image of German soldier Conrad Schumann jumping the initial barbed wire fence that later became the Berlin wall. Photo by Peter Leibing, copyright held by Ruth Leibing. Learn more at: https://en.wikipedia.org/wiki/Conrad_Schumann
