On Changing Career to Software Development (or returning to a career in this field)

In recent years, I've had people ask me for support, to help them transition to new careers in software development.

As a career, software development can be enthralling, creative and deeply fulfilling, and bring much well earned admiration and respect. It can even bring personal incomes which overlap well into the salary ranges of medical doctors. But this does not come for free.

With the people I've mentored, there has been a wide range of results. On one extreme, a young lady completed my mentorship programme in half the allocated time, and landed a prestigious junior/intermediate role with a respected US company. On the other extreme, a young fellow in a technical support role, made some noble attempts to learn development, but simply lacked the tenacity and grit to see it through.

This has made me wonder: What is it that helps some people to succeed in this field, but not others?

I've seen some people of very high intelligence, insight and analytical capability try their hardest to learn the disciplines, but give up after hitting way too many walls.

Others, I've seen pick it up effortlessly, almost like they were a successful developer "in a past life". I've even seen people who were streamed into the "borderline learning disability" classes in school, suddenly shine with brilliance in programming, with only the slightest tuition.

One amazing example was a musical composer in Sydney. After buying a mid-80s Apple Mac, he went away and taught himself everything. Within 6 months, with no support, he had written, polished and published a high-quality graphical musical composition/sequencing/typesetting app, in 68000 assembler!

So if you want to start out in software development, here are some things to think about.

1. How badly do you want this?
2. How much time and energy are you willing to sacrifice, and keep sacrificing?
3. How good is your judgement of character?
4. How good are your social and communication skills?
5. How well do you cope with frequent and repeated failure?
6. How do you rate as a "detective"?
7. How well do you handle extremes of complexity and intricacy?
8. How strong is your command of formal scientific method?
9. How good are you at inventing solutions to problems when hampered by limited time, resources, materials and techniques?

It might look unusual that I have gone against common practice and listed a bunch of "soft skills" first, before the more technical skills. This is actually very deliberate.

I can't stress strongly enough that with the right psychological foundations in place, and in the right settings, someone of even moderate aptitude can succeed more than someone of exceptional aptitude can succeed if they have psychological vulnerabilities, and/or they are working in a context that doesn't match with their personality.

Even the same person, put in one situation, can shine as a genius, but if placed in a different situation, will struggle and fail in the most heartbreaking ways.

Before I elaborate on the questions I've posed above, I'll offer a very simple definition of the role of a developer (or programmer, or software engineer, or coder, or whatever the fashionable term is in any given situation):

Software development is the art and science of figuring out (how to figure out)? how to do stuff, and then doing it,

where n is a whole number greater than or equal to zero.

Even the most advanced developers will hit situations where they don't know what's going on, and they don't know how to figure out what's going wrong. They just see a mess in front of them that defies all analysis and explanation, that completely destroys most of the understandings that have got them through in the past.

The developers who succeed are those who are willing to reach out of their mental comfort zones, to find safe ways to investigate and discover, to build up a mental model of what's happening, and figure out a plan that not only gets things working, but also, doesn't create turmoil in the future, for themselves or any other developers who happen to work on their code.

It is psychologically challenging to have to face, over and over, a situation where one feels that everything one has ever known, understood, relied upon, may suddenly turn out to be completely invalid. To feel that one is only ever as smart and competent as one's last deployment to production.

One missing letter in tens of thousands of lines of code can make the difference between a system that passes all its pre-deployment tests, then either:

1. Works reliably to the best level it can within its environment, or
2. Appears to work reliably for minutes, hours, even months, then on hitting a bizarre obscure edge case in the field, suddenly breaks down in the most damaging and stress-inducing ways, triggering a piercing emergency alarm to ring on one's cellphone at 3:11am on a Sunday morning

When things are working, when one's inventions are delivering value, it can make one feel like a magician, even a minor deity in human form. But when things fall over, it takes a very robust self-esteem to not collapse into self-loathing, and feel lower than the worst criminal.

So now we can return to the earlier questions.

How badly do you want this?

It's easy to sustain the energy to succeed in software when things are going well.

But can you cope, can you find ways to keep yourself going, when you are continually hitting walls for hours, days or even weeks? Can you trust in your subconscious invention capacity when your head is screaming full of inner voices of failure and self-condemnation? Can you sustain energy and effort, even in the face of countless distracting demands of personal and professional life?

How much time and energy are you willing to sacrifice, and keep sacrificing?

This issue alone has derailed may noble attempts to enter the software development field.

Please take fair warning that:

• Competence in development requires many thousands of inter-connected micro skills, each of which can take a lot of time to acquire and reinforce
• It's not enough to be competent; one also needs to apply competence at speed, and gaining that speed takes thousands of hours of work
• Overall, fluency, capability and speed in software development can take tens of thousands of hours of work to acquire

This is a very tough ask for someone already heavily laden with work and family commitments. If you're in this position, you need to ask:

• If you have a partner, how willing are they to support you being absent for an extra 20 hours a week, and pick up on your domestic responsibilities?
• If your partner can't support you, can your household stay afloat without your current income, for a year?
• How good are you at organising information, reflecting on your learning processes, and finding (or creating) learning styles that help you learn more, at greater depth, in less time?
• Are you willing to network with others, in a way that sustains their willingness to support your learning journey?

It's not enough to learn each specific technique, such as "writing and executing a valid 2-table join query in an SQL database, that produces relevant, valuable and accurate results". One also needs to build up a vast range of sensibilities, informed by experience, to know what mix of techniques is most appropriate at any given time, in any given situation.

How good is your judgement of character?

This soft skill is crucial. Getting onto the software development career transition path will make you extremely vulnerable, on multiple levels. You will become highly dependent on many other stakeholders.

If you know how to assess character, you will know how to find and engage with colleagues who can be trusted to nurture and support.

But if you're blind to character, you can easily miss a lot of red flags that others find obvious, and end up at the mercy of soul-destroying bullies, or people of similarly-destructive personal toxicity.

How good are your social and communication skills?

Let's get really candid here. For people working at speed in the industry, supporting newcomers to grow their competence in software engineering can be extremely draining, to the point where one's own productivity can take a huge hit.

The needed support, from others, to help you up to speed, is extremely costly to them, and to their own team and the company as a whole. Your questions will cause distraction. The explanations you're asking for, will suck a lot of time and energy. Your mistakes will cause frustration and discouragement, and weigh heavily on many people around you.

So you need to be able to offset these impacts with your own social positives. Some things that can make others feel you're a worthy investment of time and effort can include:

• Your own empathy: realising you are costing others a lot of energy and weighing heavily on them - and showing them the appropriate respect and gratitude
• Lightening of loads: if you bring some fun and laughter, or enriching insights, or fun anything that feels uplifting or good (within appropriate professional limits), that will offset the cost of supporting you, and others will actually feel ok to sacrifice time and energy
• Evidence of your own learning and growth of capability: if you need something explained once, that's ok. Twice is usually fine as well. But three, four, five times, will come across as highly disrespectful and discouraging.
• Bringing relief within your capability: if you can quickly be available to picking off some "low hanging fruit" of other developers' burdens, such as lower-skilled repetitive administrative tasks, then this will help also to pay for their effort to support you.
• Enriching communication and culture within your team: if your presence increases overall rapport and engagement within your team, and helps others to work better in various intangible ways, that will also go a long way to paying for the support you need.
• Providing insightful critique and suggestions: if your questions and comments do actually help others to achieve better outcomes, that will build appreciation, and attract more willingness from others to coach and teach you.

You can greatly reduce the cost and effort of others supporting you. In a phrase, network, network, network!

Join your local professional body. For example, IT Professionals New Zealand welcomes industry newcomers, and has mentoring programmes in place to help people at all levels of professional development.

Another great way to get added support is from joining community-based open-source software projects. Sites like Sourceforge.net and github.com have heaps of these. Search those sites for an app you like. Once you find such an app:

1. Carefully follow the published instructions to build the app from source code on your own computer
2. Find the app team's chat channels (eg Telegram, IRC, Signal, Messenger etc)
3. Build rapport with developers. Be a desirable presence to them. Show interest. Respect their time
4. Ask them questions and get help, but go easy. Don't hit them with high-load "why is the sky blue?", and "why did life evolve on this planet" kinds of questions. Ask them questions in a way that's easy to answer, and makes others feel good answering
5. Find ways you can add value to the app. If your skills are limited, contribute to the documentation, to help make the app easier to install, set up, and use, for others. Contribute graphic art if you can
6. Promote the app through various channels and networks, to expand the app's profile, user base, mind share
7. As you get more experienced with the app, be available to help out the newer incoming newcomers, and make them welcome and supported in joining the project

As you build a reputation in the app's team for helping out and adding value, they will become willing to give more and more effort helping your own learning and professional development.

How well do you cope with frequent and repeated failure?

No matter how strong you get in your new profession, you will never stop experiencing failure. How do you feel about failure in general? Can you strike a balance between the extremes of trivialising your shortcomings and glitches, versus letting them grind you down?

In this area, healthy relationships with other developers, within your workplace, and in other communities, can help a lot to put things into healthy context.

How do you rate as a "detective"?

This work is full of moments where you have very little information available on the surface. This is when you need to think like a detective. For instance:

• Be sceptical about everything. Never trust at face value. If you're driving on a country road and see newly sheared sheep in a paddock, be aware that on their sides you can't see, they may well have thick purple wool!
• Be bold about investigating
• Always see code - your own, and others' - as akin to suspects in an interview, who are cleverly and desperately trying to paint a misleading and manipulative picture, to cover up their offending so they can avoid a stiff jail term

How well do you handle extremes of complexity and intricacy?

This is an absolute must-have dealbreaker quality of character.

When faced with an extremely high-complexity situation, can you slow yourself down and carefully "spin hundreds of plates" mentally, so you can figure out what needs sorting? Do you have the patience to navigate your way through a seemingly impossible maze?

Or does complexity cause a lot of stress? Do you hunger for simplicity? Does complexity such your energy and demotivate you?

How strong is your command of formal scientific method?

Expect often to land in situations where nothing makes sense. For example, a fault occurring intermittently in a large international mesh of inter-connected networks.

All the code has passed its unit and integration tests. It has been running solidly for weeks, or months. All the diagnostics you run show that things are completely healthy. But what you're now seeing, is that things seem hopelessly broken.

You may be a victim of all kind of things, many of which are not your fault, at least not on the surface. For example, you may have:

• Trusted and acted on documentation written by others, which in some situations proves catastrophically inaccurate
• In your unit tests, missed out on a very obscure combination of factors which almost never occurs
• Relied on resources provided by others - such as network connections, computers, software packages - that may have a great reputation for reliability, but fail unexpectedly

In these situations, you need to perform dozens or hundreds of small tests. Often, you will have to write programs ,on the spot, to perform these tests. Use the scientific method discipline of: form hypothesis, devise test, test hypothesis, confirm or refute hypothesis, wash spin rinse and repeat. This will get you through the most impossible situations.

How good are you at inventing solutions to problems when hampered by limited time, resources, materials and techniques?

I'll give you a recent personal example, completely outside of software.

I had hired a high-power petrol generator to provide household electricity during a long blackout, necessary due to a planned maintenance upgrade. The hire shop loaded the 350kg generator into the back of my car with an electric crane cart. I got it safely out of my car by wheeling it down a makeshift plywood ramp.

But when it came time to return it, I could not push it back up the ramp into my car. I lacked the physical strength for this. Time was running out, because if I didn't return it within the hour, I would be charged for another day's hire.

I had no block and tackle, so I improvised a crude 4:1 leverage rope, anchoring at my handbrake mounting. It partly worked but the ropes' range of movement only got it part way up the ramp. Still no good.

But I did have a couple of old car tyre jacks. I put these under the ramp and cranked them up, which was enough to lift the generator and reduce the angle of the ramp. Then, I was able to use the rope with a lesser 2:1 leverage, to get the generator more than half way up. Then, I was able to put wood chocks under the ramp where the jacks were, to free up the jacks. Then I put the jacks themselves on more wood chocks, and got the ramp higher still. With this, and a much more level ramp, it was now within my strength to push the generator the rest of the way up the ramp and into the back of the car, and return it on time.

This is such a typical situation in software development. Things work fine, until or unless they don't. And, when they don't, you have to be capable of fast, creative, intelligent and safe improvisation, using often very little in the way of tools and documentation.

You have to "figure out how to figure out how to figure out what's wrong", then "figure out how to figure out what's wrong", then "figure out what's wrong". Then, go through similar rabbit holes to figure out how to fix it, in ways that don't cause breakage or worse issues later.

Milestones to Success

For a developer entering the industry, there are several milestones to professional success. It can't be emphasised strongly enough, that hiring developers is extremely expensive, demanding and risky for any employer, especially smaller businesses.

Even if a developer's hiring works out well for a company, it can make the company worse off for months or years, until the developer reaches and crosses a break-even point, and gives their company a positive return on their investment.

Here's a rough list of some of the success milestones, in very rough order:

1. Finding prospective employers and recruitment agents who are actually willing to engage in conversations about employment possibilities
2. Getting to formal interview stage
3. Getting onto the candidate shortlist, being taken seriously, and getting through several stages of interviews and tests
4. Getting and accepting an offer of employment
5. Gaining competencies and understandings on the job in demonstrable ways
6. Becoming capable of accomplishing relevant tasks, under close supervision and support, in less than three times the time it would take the supervisor to do the job themselves
7. Becoming capable of performing a task -- independently -- in less than three times the time it would take for more senior colleagues to do it themselves
8. Becoming a 'net positive contributor', where the cost of one's own salary, plus the cost of time of colleagues providing help, is less than the cost of a more senior colleague doing the job themselves
9. Crossing the individual break-even point, where the total cost of one's past salary, plus salary of others who have helped train and support (with interest), is now less than the value one has delivered in this time.
10. Crossing the broader break-even point, where one has delivered value that has not only paid the cost of one's own hiring plus the salary costs of support received from others, but also, has more than compensated the the losses incurred from hiring others who didn't work out

Please always be aware that one of the greatest parts of the value you bring to an employer, is your ability to work things out independently, and your progress in weaning yourself rapidly off all need for support in as many areas as possible.

On the other hand, staying in a state of high dependence greatly reduces your value, and even keep you stuck in a state where you are a chronic liability, where the company stays much worse off from having hired you.

Independent capability is absolute gold! So build this as soon as you can!

Wrapping Up

This article has covered a lot of the issues one can expect when transitioning to a career in software development, and a lot of the issues employers go through when bringing new developers on board and getting them up to speed.

Making this transition is a massive and costly investment of time, effort, and even finance. But for those who accomplish this transition, the career in development can be unbelievably exhilarating and fulfilling in ways that pay for the investment over and over again in the decades ahead.

Hopefully this has given you a few things to think about, to get better clarity about whether a move to software development may be viable and right for you at this time.