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.

Step 1: Get some skills

The first thing you need to do if you want to become a developer is get some skills. HTML, CSS and JavaScript are key to frontend development so go find an online course and get studying.

• w3schools.com - A great resource for entry-level HTML, CSS, JavaScript, jQuery and much more.
• HTML Cheat Sheet - A full list of all HTML elements including descriptions, code examples and live previews.
• CSS Tricks - Lots of tips about CSS, HTML and JavaScript from a frontend perspective.
• TailwindCSS - A highly customisable, low-level CSS framework for rapidly building custom designs.
• CodePen - CodePen is an environment that allows you to see the direct result of your code without setting up an full-featured development environment.
• GitHub - A code hosting platform for collaboration and version control, GitHub lets you work with others on projects.
• Code Academy, StackSkills, Udemy, Pluralsight - Lots of great courses, free or for a fee, with more available all the time.

Step 2: Build something

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.

Step 3: Expect to get lost!

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.

Step 4: Get a job

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.

I did it. You can too!

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. ??‍♂️

Coding Labs runs an Intern Developer program for motivated students or graduates who want to get commercial skills in Laravel, Vue.js, CSS and HTML. ?Learn more ?

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:

1. What is the overarching workflow that governs timing and workload management?
2. Which project management software can support the workflow?

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.

The early years: 2005 - 2018

Paper

Photo by Steve Johnson on Unsplash

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.

DIY

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.

* Don't try and build a DIY password storage system. Get a real password manager like this or this.

Basecamp

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.

Jira

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

Google Docs

Photo by Glenn Carstens-Peters on Unsplash

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.

Clubhouse

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:

• Where do I put the stuff that is not development-ready?
• How do I share this tech-jargon heavy interface with clients?

Back to Basecamp: 2019

Photo by Jason Leung on Unsplash

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:

• We are now a team of 3 full-timers, with an part-time team of interns and freelancers sometimes fluctuating to 10 or more
• We work with a diverse list of clients, and sometimes projects work better when you can invite the client onboard to collaborate in a straightforward interface, while maintaining control over what they can see and do.
• There is a lot of documentation and written processes underpinning "the way we work". It is annoying having documents dispersed around various locations including Google Docs, paper, PDF and our collective memories.

Basecamp is currently solving all of the above issues (and more) for us.

What about the workflow?

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:

• The non-workflow (staring down the barrel of hundreds of to-dos with no higher order organisation)
• Quarterly milestones
• Monthly milestones
• Continuous sprints
• Story point estimates
• Time based estimates
• Time tracking software

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:

• Flexibility needs to be built in
• Automation and repeating tasks go a long way to establishing process-driven consistency
• Free-time and downtime need to anticipated and protected rather than an afterthought when the burnout bites
• 10,000 foot views provide a useful oversight of the big picture, but thinking about the big picture every day is overwhelming
• Trying to predict everything before starting to code is impossible
• Trying not to predict anything before coding leaves you rudderless 
• Long term plans and software development go together like chalk and cheese

Introducing the 2-Month Work Cycle

Borrowing heavily from Basecamp's inspired workflow, at Coding Labs we settled on a 2-month workflow cycle.

Why? 

• lower lead-in time for new projects 
• More predictable workload 
• Less opportunity for feature creep 
• More agile to changing requirements 
• Demands tightly scoped planning 
• Avoids risky long term planning / commitments 
• Systemised preview and review processes

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.

The Scrapbook

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.

Pitch Week

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.

Build

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.

Review

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.