If you're asking yourself - Can I become a developer - the answer is yes. Yes you can but it won't be easy.
You want to be a coder and don't know where to start?
You're not alone. Developers, software engineers, UX designers, mobile developers, cloud engineers, blockchain developers, AI developers are all part of the top 10 most in-demand tech jobs in 2019.
A career as a developer offers job security, above average income and the chance to work with leading edge technologies. The average salary of a full stack developer in Australia is $110,000 according to neuvoo.com.
Most courses quickly get you into building a small 'Hello World!' project because there's really no other way to learn to code, then by doing it. Replicate small unambitious projects you've found in your course or video, starting with tutorials and improving with documentation.
You'll find tutorials on GitHub, YouTube and on many of learning platforms listed above. Use them to get you to a starting point where you can experiment and change things.
Documentation is the source you should always be learning from. Every framework or library has its own and whether it's good or bad, it's where you need to go back to master that particular technology.
Don't forget Google! Google is your best friend when you've got a problem because it's better than Stack Overflow or anything else for finding a fix or solution for your problem.
Getting lost when tackling a problem or learning something new is commonplace when you're learning to code. The pace of change in development technology is frenetic and even senior devs with 15 years experience get lost sometimes.
In the path of learning to code you will have moments of self-doubt, discouragement and crises of confidence. You will think, like I did, that 'you just aren't getting it' and you'll never be able to do the most basic job that a developer does.
But don't give in! Every little bit of learning you gather, piles up and eventually aggregates into understanding. And suddenly things add up - you'll solve a problem, understand where you'd didn't before and things will get a little clearer. Go back to your tutorial or the documentation and read it again with newly awakened understanding.
The whole object of this exercise so far was to get a job as a developer so don't waste time. Put your CV and portfolio together and start applying for Junior Developer roles.
Your portfolio is the key element here. You should have a handful of public projects that showcase your skills. They don't need to be polished but they do need to show improvement in your skills from one to the next. Don't delete your early projects, no matter how bad the code is. When we're looking for candidates we are interested in those who can learn and improve - everyone's first projects are terrible.
Expect to complete an assessment task - this is common practice for most employers in the tech space. Read the documentation of your chosen language or framework again and practice common tasks. You'll find plenty of examples online.
Don't waste your time talking to recruiters. Employers aren't interested in paying a recruitment fee to find a junior so you'll be wasting your time. Instead look for direct employer job posts, follow likely employers on LinkedIn and network with other developers to hear about opportunities when they happen. More than 80% of jobs come through your network rather than from responding to a job advert so apportion your time appropriately.
Find an employer that is a fit for you. Evaluate the employer as they interview you. Ensure the job is one you'll enjoy and that gives you the opportunity to learn and develop. Find out if there are resources such as senior developers, libraries, sponsored learning or training programs that will develop further skills in your chosen field.
Communication is often a hard-to-find skill in a developer so demonstrate your strong verbal and written skills at every opportunity. Strong communication skills will make it easier for you to work effectively within a team, interact with other employees and with clients. Your communication skills may sway the hiring decision and quickly cement your place in the team.
You CAN do it.
I became a front end developer in just 3 months and I'm well on the way to becoming a backend developer after 5 months. It's a challenging journey but well worth the effort.
Give it a go - I'll be cheering for you. ??♂️
I must have tried at least a dozen project management tools and workflow strategies since my first commercial project way back in 2005.
A development workflow that consistently delivers is without a doubt one of the biggest recurring pain points in a software developer's life. Even with regular fine tuning, what works one month might not work at all the next.
The reasons for workflows frequently breaking down are varied, but some common reasons include scope changes, personnel changes, unanticipated events or non-work life events.
There are two abundantly clear dilemmas to solve for any software development team:
Touch wood, at Coding Labs, I think we have answered both of these questions for the foreseeable future, leaning heavily on the inspired thinking and products created by dozens of others.
It goes without saying that no system is perfect and what works for us won't necessarily work for others.
But before I dive into the 2019 strategy, here is a summary of some of the strategies i've tried.
Often a great place to start is the good old pen 'n paper. In fact I still use this method regularly during meetings or when I am well and truly stuck on a complex task.
On the downside, it does not scale to other people (especially if your handwriting is as illegible as mine), it is extremely messy, environmentally wasteful, and you can't access it remotely.
Following the "scratch your own itch" wisdom, and with the added benefit of documentation that could survive an overzealous desktop cleaning effort, in the late 2000s I developed my own internal project management software that kept my to-dos organised, supported client log-in, and even had a rudimentary password vault*!
Like a lot of my DIY experiments over the years, this project also fell in the basket of don't be a tightass, stop wasting time and find a fully featured product for ~$10 a month to do this thing.
To my great joy, I recently discovered that my original Basecamp account from way back still existed, and even better still, had the same original UI!
Basecamp was pretty good for me in some ways (certainly much better than my DIY efforts), but nagged at me in other ways as I learned more and more about agile workflows and sprint development.
It felt geared to marketing types whilst my interest was pivoting strongly towards application development with more complex needs.
Enter the King, the enormous monstrosity that is Jira*.
The project management tool that literally does everything you can think of.
In many organisations Jira has a specially trained staff person just to circumnavigate the settings, let alone utilise it to its full potential.
I had a good 2 year run with Jira, the integrations, analytics and reporting are fantastic, and when used properly can do powerful things.
* In fairness, Atlassian appear to have recently made substantial progress on lowering the barrier to entry for Jira
One of the frustrations in a lot of project management solutions, is that they do some things well but omit other features because some other SaaS product does it better.
For example, how good is a plain old word processor to formulate a written plan, or even just used as a bit of a dumping ground for ideas that are not quite development-ready, but still worth noteworthy.
I briefly flirted with Google Docs as a pseudo project management solution, and yes, it lasted about a month before it fell apart at the seams.
With the inevitable breakdown of Google Docs as a viable task manager, I was back on the hunt. On a recommendation, I gave Clubhouse a try.
Like Jira - with an unmistakable focus on software developers - but without the kitchen sink; Clubhouse looks and works great right out of the box.
Again with solid reporting features and probably the best milestone, epic and to-do list functionality i've ever come across (bulk to-do editing ftw ?), Clubhouse held its own for about 18 months.
But there were still some nagging questions:
History repeats, and for me that meant returning to Basecamp at the beginning of 2019 after almost a decade long hiatus.
In the interim, a lot of things have changed at Coding Labs:
Basecamp is currently solving all of the above issues (and more) for us.
I have spoke at length about the tools I have used, but not much about the overarching strategy that guides how we estimate, budget and allocate time.
The truth is, I have tried just about as many workflow strategies as I have project management tools. To list a few:
Perhaps my scrum master gospel just ain't up to scratch, but what I always find is that sooner or later, a project reaches a stage of decision-paralysis, with so many good, worthwhile ideas; but for various reasons, the work that gets ultimately shipped does not come from the great ideas basket, but rather the this-is-more-urgent basket.
On the estimating front, an estimate for a task bigger than about 10 hours is not worth the paper it is written on.
At the start of 2019, I decided to strip our processes right back to barebones, and re-think our workflow from the ground up. The things I have figured out over the last 14 years are:
Borrowing heavily from Basecamp's inspired workflow, at Coding Labs we settled on a 2-month workflow cycle.
Part of the carry-over benefits of moving back to Basecamp, is that there is no room for ambiguity about "where things go". If it relates to project management, it is in Basecamp.
For the most part, ideas start in a per-client document called the Scrapbook. This is a semi-organised collection of pre-pitch ideas and incidental backlog items that are not ready to be actioned, but still worth remembering.
In the first week of a cycle, we start harvesting Scrapbooks for ideas and liaising with clients about what they prefer us to tackle next.
There are no hard and fast rules here, the chosen work just needs to be big enough to be worthwhile, but small enough to be achievable within the timeframe.
The winning ideas proceed to a dedicated project in Basecamp, each with its own guiding Pitch. The Pitch details in broad strokes the who, what and why of the project.
Each Pitch is very much a living document and subject to change during Pitch Week as the underlying tangible result emerges from the rough.
The Build follows on from the Pitch in roughly two halves.
The first half is all about further refining and assigning the actionable tasks that have emerged from The Pitch. As time passes, we establish a strong grip on exactly what will be built through prototyping and validating ideas.
The second half is all downhill. We know exactly what we are doing and we go about getting the job done. We test, review and try and break things. Time permitting, we look for opportunities to add a final coat of polish.
At both the individual project level and as a company, we take a look at how we performed, tie up loose ends, celebrate victories, and look for ways we can do even better the next time around.