10 things beginning software developers must know these days …
… that are not coding
Long-long ago-ago, when first I coded for pay, people could get paid just for coding, and nothing else besides. Companies gladly hired Computer Programmers (coders) and Analyst Programmers (coders who could hold a brief conversation). If you could write a little Pascal or C that would compile and run, without crashing every time, it was enough to keep your job.
It didn’t even have to be good Pascal or C. Error messages, hanging UIs and screens-of-death were tolerated as mild inconveniences, given the huge new advantages of computerised systems over paper-based, manual process.
Now, not so much. If you’re thinking of looking for a first job in software today — maybe you’re doing some courses on freeCodeCamp or Udemy, or building your first website as a hobby — learning a programming language will only get you about half way towards employability.
Here is my list of the things you’ll need to know about to get a foot in the door. (It’s roughly in order of importance.) You won’t need hands-on experience with all of them— but not being able to talk about them could be a barrier to entry.
1. Git, git, and more git
Version Control Systems (VCS) and Source Code Management (SCM) let you save versions of your code, so you can revert back if you make a mistake, and merge your work safely with what others on your team have done. There are many SCM systems, but nearly everyone chooses git. Git was created in 2005 by Linus Torvalds, who also made the Linux operating system. By now, it’s just about everywhere.
When you join a software team, they’ll have their own specific way of using git. If you know the basic git commands and what they do (push, pull, fetch, add, commit, …), you’ll be in a good place to join in — and your newbie questions will sound clue-full not clueless
2. The Testing Pyramid
A reason why most apps and websites now work reliably, and don’t always crash, is automated testing. Developers write extra code to check that their application’s code does what’s expected of it. You should know the purpose of the main kinds of automated and manual tests.
- Unit Tests check that each smallest component of the software (called a Unit of Work) does what’s expected of it. Typically, devs write Unit Tests to cover nearly all of their code. Unit Testing is not meant to show that the application works overall — you can think of it more like scaffolding that helps a team build their application safely. Better teams write the unit tests first, then write code to make them pass.
- Exploratory Testing. After making a change, a developer should spend some time checking that the application does what’s expected. This means running the code and looking for anything that isn’t right. Exploratory Testing is a type of ‘Functional Test’.
- Integration Tests check that the components of the software interact correctly. They can be automated or manual.
There are many other types of test too (component tests, system regression tests, user acceptance tests, etc), but as a starting developer you won’t need to be too familiar with all of them.
3. Objects are still a thing
Interviewers used to make a big deal of object-oriented programming and its principles. It’s not stressed so much these days, but you’ll still need to be able to talk about this stuff, if asked. Look up the following, and be ready to say something sensible: inheritance; polymorphism; SOLID; O-O design patterns.
If your interviewer is tricky, they might ask about Functional Programming too. At least know how it differs from Object Programming.
4. Cloudy, with a chance of events
There’s no such thing as a standalone application anymore. Every piece of software interacts with others. This can be getting data from an API over the internet or from a database. It can be sending and receiving messages using a message broker system. It can be distributed systems — where lots of small applications work together.
Starting out, you won’t need deep knowledge of all of this, but you’ll need to be able to explain things like microservices, event-driven design, and cloud computing at a basic level.
5. Signs of numeracy
The good news, if you’re coming to coding without formal qualifications, is — most of the theory people learn in Computer Science degrees is completely irrelevant to most development jobs — and most hiring managers know this. Unless you’re applying to Google, nobody will expect you to know anything about Time Complexity, inverting binary trees, or the Lambda Calculus.
The bad news (maybe), is that you will need to do some reasoning with numbers. Swat up the very basics of statistics (means, medians, standard deviations, … ) arithmetic (precision, modular arithmetic, significant digits, etc) and discrete mathematics (logic, sets, graphs, combinatorics). This applies whether you plan to build cute web apps, business systems, games, or pretty much anything else.
6. Our new robot overlords are you friends
Your first year in a commercial coding job will be a daily struggle with confusion. Accept this — but don’t make it harder than it needs to be.
AI programming assistants (GitHub Copilot, AWS CodeWhisperer, Cursor, ChatGPT, etc) will make your life a lot easier. Just don’t trust them completely. Try their outputs and see if they work. Make small changes to their suggestions and see what breaks or gets fixed.
7. Love your Tools
Modern Integrated Development Environments (like Visual Studio, XCode, IDEA) provide lots of support to understand what your code is doing.
If you don’t know how to effectively do step-through debugging, check the call stack and the value of all variables, and go to the implementation of any function, you’re making things much, much harder than they need to be. Spend almost as much time understanding the developer tools as you do understanding the code.
8. DevOps & the lifecycle
Nobody will expect a junior dev to be fully up to speed with all the ways of teamworking that get talked about in software engineering organisations.
However, the more of this jargon you know, the less lost you’ll be. Do some quick reading about: Agile; Scrum; Kanban; the DevOps approach; CI/CD; Flow Metrics; DORA; BDD. Know what a daily stand-up meeting, sprint planning and retrospective are for.
9. Rules for a lot of thumbs
There a many different rules of thumb and heuristics that help us write quality code. Get comfortable with many of: YAGNI; KISS; DRY; Curly’s Law; The Boy Scout rule; Least Astonishment.
10. I am a Professional Engineer
Although this one is last in the list, it might be have the biggest impact on how your software career progresses. Even if the software you are building has a fluffy or trivial function (maybe it’s a horoscope app or a screensaver with cat pictures) you should treat it like you were building a safety-critical piece of infrastructure (think, a power grid or an air traffic control system).
Constantly ask, what could go wrong here, and how could it affect people using my system or the other systems that it interacts with. Be cautious, be ethical, be inquisitive. Test, test, and test again. This will put you far ahead of the pack of entry-level coders.
So, that’s it. These 10 points shouldn’t be daunting, or require years of study. Just learn the basics of each point and extend your understanding over time. Most of all, enjoy the learning curve. You’ll get there, because you’re amazing!
