Lessons I've learned from starting a new tech role

Two months ago, I started working as an Apprentice Technician for Arm. I've always been interested in programming, but this was my first formal role in a tech environment, and there's been a lot to learn from the beginning. In this post, I wanted to share some of the lessons I've learned from starting a new role in the tech sector. Some of these tips are specific to programming, but some are not - so if you're starting afresh in any industry, I hope you get some value out of this post.

1. Don't be afraid to ask for help

... But only after you've exhausted all other options. I think it's easy to keep asking questions when you start a new role and everything is new, but there is a value in taking time to figure things out for yourself. My general rule of thumb is to ask for help if I'm stuck and making no progress on the same problem after an hour or two.

And similarly ...

2. ... There's a right and a wrong way to ask for help

I think that there's a reason StackOverflow has such a well-defined and moderated etiquette for asking questions - it's because it works. It helps people to get their problem across quickly, and allow people to answer questions more easily. The SO etiquette can be summed up as:
  • Give as much detail as needed to answer the question - not more or less
  • Tell us exactly what you've tried already
  • Demonstrate that you've made an attempt to solve the problem yourself
  • Keep it simple and to the point.
I think that the same set of principles applies to asking questions in any business environment, but definitely so in a tech environment, where it's especially important to make clear what the nature of the problem is and what you've already attempted to solve it.

3. Don't try to generalise to all cases before writing code

A mistake I've often made when coding in general, is opening a new program, and starting to write code that I think will address every single possible use-case, before writing working code. It quickly gets confusing, messy, and I often forget what I was trying to do in the first place because I'm so caught up in making my functions and class definitions perfect, that I'm not achieving even one of the cases I wrote the program for in the first place.

This is different if you're approaching a structured and planned project, where it is important to have an upfront idea of what you're doing. But sometimes the iterative approach is more helpful - getting something working before you get everything working.

On a similar note ...

4. Avoid perfectionism

Perfect is the enemy of just-about-does-the-job, when you're writing something new. That's what testing is for, later on. At least, in my opinion.

5. Break down new concepts, and identify your learning dependencies

When you're new to programming and tech in general, learning new concepts can feel like climbing a mountain. It doesn't have to. It sounds trite, but breaking down concepts and starting on the basic ones, then working your way up, is essential to make sure that you don't get discouraged or get overwhelmed by the amount of information you feel like you have to learn. If you need to know how to write a command-line program in Python and don't even know how Linux works, start with Linux, then command-line tools, then Python, and so on.

In second-language teaching, there's a concept called "i+1", also known as the "Input hypothesis". The idea is pretty simple - gauge how much students know, and teach them language that's just a little bit more advanced than their current level. If the student knows how to form the present tense for a regular verb like "I learn", teach them the past tense "I learned", which is one level above their "i", or current level of knowledge. Don't teach them a monologue from Hamlet. Similarly, if you're new to the tech field, it's easy to try and jump straight into advanced topics. Don't. Work at the level you understand, and learn concepts that are just a little bit more advanced. It's i+1, not i+5.

Another way to think of this is to understand your learning dependencies. For example, if you're trying to build a website, there are several things you may need to know, such as how to write HTML, CSS and JavaScript. In order to learn JavaScript, you need to know what a scripting language is. In order to know that, you need to understand the concept of programming languages in general. To get to the point where you understand programming languages, you need to know how computers work ... and so on.

This is a simple example, but for overwhelmingly complex concepts, it can be helpful to map out your "learning dependencies", so you have a clear idea of exactly what to learn, and in what order. If you try to learn how to do something you haven't got the pre-requisite knowledge for, it's obviously not going to go as well.

Here's an illustration for what I mean by "learning dependencies". Imagine each box indicates a concept or knowledge, and every box linking to it is a concept you need to understand before you can fully grasp the concept itself. This is what I mean by a "dependency" - you can't learn one concept until you've learned all of the related concepts.



6. Be curious ... the right amount of curious

When you're going into a new field, it's really important to be curious and find out as much as you can. It reflects positively on you if you're interested enough to look beyond just what you need to know to fulfil your job role. But the nature of the job will mean that you could probably spend years learning more about every single concept you come across. Try not to overwhelm yourself in detail, and build up your knowledge slowly - this links back to the "i+1" concept discussed above.

7. Keep detailed notes, and refer back to them often

If you're learning how to use Linux for the first time, keep a text file for basic Linux commands. If you're learning how to use SQL to query a database, fill a word document with every SQL query you write and put each under a descriptive heading, so that you can come back to them when you need it. If you find a great explanation of a particular concept, bookmark it, save it, put it in a clearly labelled folder. It's less helpful learning something once if you have to keep Googling it again and finding the perfect resource or explanation. Keeping notes isn't just something for college and university - effective note-taking forces you to understand what you're doing, or exposes the bits that you don't understand. If you're writing something down and not understanding it, then you know exactly what you need to do more research in. Is there a learning dependency that you need to gain knowledge of first?

I try to go with the principle of writing notes so that someone in the exact same position as me would be able to pick them up and understand what's going on.

Similarly, comment every bit of code that you write. Unless you're just writing a "Hello World" program or experimenting with syntax - if the code is going to be used for anything, it should have descriptive comments. Not just for other people - you might come back to your code later on, and forget what it's doing and how it works. Comment for your future self, and for your colleagues who might look at that code some day.

8. When learning a new language, walk before you try to run

It's easy to get excited when learning a new programming language, and try to do everything at once, or get far ahead of yourself. When you're a beginner to a language, make sure you're practising the basics and building up your skills bit-by-bit. If your end-goal is to write a program which manages your to-do list, make sure you know how to manipulate arrays and strings before you start writing complicated functions. Again, make sure you're following your learning dependencies.

9. When things don't work for any good reason, try rewriting the code from the ground up

Sometimes there's no obvious reason why you're getting a bug. If possible, it can help to start from scratch and rewrite a minimal functioning example of your code to test that each component is working again. It goes without saying, too, that you should get familiar with your debugging tools for whatever language you're working in. If it's Python on the command line, get familiar with the Python PDB tool. If it's Visual Studio Code or a similar IDE, make sure you understand the debugging tools given to you. Proper debugging tools will save your bacon when things go wrong.

10. ... Or comment things out until they start working

And sometimes the opposite approach is needed. If you've introduced code which breaks the program, you may need to comment things out until you work out exactly which bit is doing the breaking.

11. When you're really struggling, walk away from the problem and come back to it with fresh eyes

This is the advice that I need to remind myself of on a regular basis. It's too easy to spend hours without breaks staring at the screen, going through every debug option trying to work out what exactly went wrong. Sometimes it's also easy to get caught up in a particular niggle and forget what you're trying to do overall. There might be a simpler method you haven't accounted for which avoids the problem you're getting in the first place - or the task you're spending so much time trying to achieve might not be as important as you think it is. It's essential to take time away from the problem to get a clear head, and come back to it with a fresh perspective.

And on that note ...

12. Take regular screen breaks, and take care of your health

This should go without saying, but depending on your role it may be easier said than done. Especially if you're working from home, it's vitally important to get enough screen breaks. I know when I haven't done taken enough breaks because I start feeling drained and getting headaches. It's a good idea to look away from the screen at least every 20 minutes, and take at least 5 minutes every hour to walk away from the screen and do something else. Get a cup of tea, step outside and go for a quick stroll, or just sit next to a window and watch the world go by for a bit. If you need to, set yourself a timer - there are countless apps such as the Break Timer extension for Google Chrome, which also has a desktop app.

It's not just your eyes that need a break, though. Working from home can be tough in general. If you're working from home during the pandemic, make sure to look after your health as much as possible. Take time to go for walks where it's safe to do so; find some form of exercise; drink plenty of water throughout the day; and try to get enough sleep.

Lastly, and perhaps most importantly:

13. Make sure that you draw a line between work and home

Perhaps the toughest thing about working from home is drawing the boundary between work, and home. This can be a lot more difficult for some than others, depending on your living situation, family, partner, children and so on. If you have the ability to set up a dedicated space for work - separate from the spaces where you relax and sleep - do so. Working in bed makes it harder to draw the distinction between your personal space and work space, and makes it far less relaxing when you do go to bed, because you're still psychologically in your "work zone". Make a clear distinction between the places where you do work and where you relax after work, as much as it's possible to do so.

I also strongly suggest treating working from home the same way you would treat going into the office. Wear smart clothes, and keep them ironed - don't turn up to work in your pyjamas, even if no-one else will end up seeing you. Put away distractions as much as possible, and aim to focus solely on work when it's in working hours (again, personal circumstances allowing.) The psychological effect of dressing up for work means that you feel more productive and motivated to get things done.

-

These are just my opinions, based on my experience so far. If you're reading this, I hope you found this useful.

Take care.

Comments