I recently wrote an article about being an unemployed junior developer, coming back into the industry after 20 years at the age of 40.
Now I'm abo...
For further actions, you may consider blocking this person and/or reporting abuse
Great questions, each worth an article on their own but I'll try to give some advice right away.
It took me 2 years from the point where I decided I wanted to get back into tech. There were several near misses along the way, so it could have gone faster. There was also a period where I fell victim to the feeling of simply not being good enough to be employable. I know there were some opportunities that I didn't get simply because of my age, but I can't blame that alone. Also, I am sure that it would have gone faster had I lived in one of the larger cities.
This is a big one. We all have different ways of learning and our lives allow a different amount of time to be put towards that. Here are a few tips I believe everyone can use:
Those two points are about learning what other devs that you will probably work with are doing. You must have read a lot about soft skills by now and to delve into other areas than your own is the best way I know to make yourself a better co-worker.
Git and Github. Learn Git, use Git. Learn Git more. Learn the Git workflow and use it for all your personal projects. Merge feature branches into your dev branch and then merge your dev branch into your master branch when it's stable. Do this even though it is overkill on your own small projects. Learn what rebase is and how to do it. Learn why force push is scary. Learn how to commit often enough to have meaningful commit messages.
Once you are comfortable with Git, help out with an open source project. Even if it's something tedious and simple like renaming variables or updating readme files. Do it as soon as you are comfortable making a pull request.
Apply everything. Even if it's in projects you won't finish, don't just read or watch youtube, sit down and apply that knowledge in something of your own. Don't just follow a tutorial but rather apply the knowledge in projects that differ from what they made in the tutorials.
Set up goals, preferably projects that you want to make, and make a study guide to reach that goal. List what you need to learn and learn them one by one and then make that project.
Learn how to code, not a language. No matter what language you like, don't learn just that language. Try to apply what you learn in more language than one, even if you aren't going to use that language in the future. You'll understand your preferred language better when you can compare it to other languages.
Git, seriously, don't forget about git.
Be social. Go to meetups if you can. Blog. Read other blogs and articles and comment on them. Make friends that code. Write articles on Medium and Dev.to. Contribute to open source. Put stuff on github. Be honest, always be honest. You are not a product so don't try to sell yourself.
This question has two answers:
This goes with the advice earlier about being honest. You are always knowledgeable enough to write about your experience. Your experiences are not magical and while you aren't the top authority on any subject nobody can argue against your experiences. Nothing here is written from a perspective of the best coder that has ever lived, they are just the experience of one person. I'm willing to share how I see things and what I've experienced but if I thought that you would read this as the ultimate truth I wouldn't have dared write a single word.
My advice is to do everything before you feel ready to do it. Contact companies before you are ready, contribute to open source before you are ready, write an article before you are ready, go to meetups and hackathons before you are ready. As long as you are honest and don't try to sell things that aren't true you'll be just fine and you'll learn a lot more than if you just sit in the dark by your computer. If you are waiting until you are ready you'll keep on waiting.
So, these were short answers to great questions that deserve more. I'll take a couple of them into the next article and have written some ideas for another article based on the others. I'll include some resources for more information in the articles as well.
When were you diagnose with ADHD? I was diagnosed with ADD when I was in elementary school here in the US. I was around 10-13 years old when I was diagnosed.
What, if any, impact do you think it has on your career or daily work activities?
I got my diagnosis at 30, when we were expecting our first kid. I like to differ between ADHD diagnosis and my ADHD personality. The reason for the diagnosis is to make my interaction with the world easier. It gives me access to meds that help me and is a good way to bring up how a workplace can adapt to get as much out of me as possible. My ADHD personality, on the other hand, is a big cause for frustration as well as a big source of joy. I would not be as creative as I am without my ADHD. I wouldn't have jumped down every rabbit hole I've found, building a broad knowledge and understanding in the process, had it not been for my personality. It makes me an explorer, a problem solver, an accelerator and a force for momentum. At the same time, it takes a lot of work to keep me going in the right direction, to keep me going steady over time and to slow me down so I can focus on the details.
ADHD is a big topic and I've been lecturing about it for a decade now, so I might write an article about that as well if there is interest.
Reading your story is comforting. I started coding only six months ago and have been in an 'internship' for 3 months now and looking for the next step on the ladder. It's been a tough process to stay focused as I have also just been diagnosed with ADHD (I'm going on 34 soon), I also suffer from depression.
Hearing that you have been able to break down the barriers and get on with things and find work in the field has given me some more hope.
Thank you for sharing your story
I can add that I also carry a depression that takes work to keep at bay. I've been lucky to have a wife and a best friend who I can talk very openly about this with. Thanks for sharing back. =)
Some of the techniques that help me. Is being in touch with my emotions and my body. If I am staying still for a bit, then maybe I just need to get up, get something to eat/drink or use it as an opportunity to talk to a co-worker about something.
Stretching and moving my body while I am sitting also helps with that.
Another thing that helped me was snacking or chewing gum. Having something for my mouth to do really helps. I connect it with when I would tap my foot or pencil at my desk in school. I just need something to do that is repetitive, but doesn't require my attention so my mind can focus on what I am working on.
And lastly, having a routine. Whenever it is. For me the first thing I do is walk the dog, take some medicine and vitamins, and then give him food/water.
Likewise at work, I'll check emails, issues I am assigned or that may impact my work. Essentially, I have a checklist that I do when I am work usually updated based on my progress. Then I go to lunch and go back with mini-breaks in-between (see the first paragraph).
It's all about paying attention to what works for you and what doesn't and learning from others.
Really encouraged to read this post! I'm 34 and trying to get to a reasonable level of skill having messed around (badly) with coding since I was a teenager. Gives me hope that I'm not wasting my time completely on this endeavour.
I was in a similar situation at around that age. I spent over a decade in a clerical job, the last four years of which I was trying to get out and into web dev.
I finally managed it at 32, but I could have done it faster if I'd focused more closely on being able to build a full-stack web application - instead I flitted about between learning several different languages. If I'd instead built something real and useful I'd have got it done much quicker, so my advice would be to build an application or two that would be useful to you - you'll learn more from that than going through endless tutorials.
That's encouraging to hear! I've got a small project I'm working on side by side with going through tutorials. I think it works well because it really forces an understanding of what you are trying to work on when you have to apply the ideas to a new situation. I find when just working through a tutorial that it can often go in one ear and out the other without ever really lodging in the brain.
They call it 'tutorial purgatory' when you get stuck in an endless search for tutorials. You go through them and create exactly what the tutorial tells you to and what you learn is to copy text. The solution is to do exactly what you are doing, constantly put what you learn to use in situations that differ from the tutorial.
Any and all coding you do is useful but always more so when you don't copy someone else's solution. When you are to create something it doesn't matter if it's your code or not, the result is what matters. When you learn, on the other hand, it matters a lot. You don't want to learn syntax or algorithms, at least not only that. What you want to learn is how to solve problems with code and to learn that you need to solve problems with code.
I hope you stick with it and get to work with things that are challenging and feels worthwhile. =)
Have you stuck around in the same company? If you've moved to another position or company, do you feel that once you got the foot in the door, in the industry rather than the company, it was easier to find the next position?
I've worked for four different companies for any length of time, and it was definitely much easier afterwards.
In 2016 my then-employer went into liquidation, so I was made redundant and had to find a new position. At that point I was coming up to five years in the industry and I had never before had such a high proportion of offers to interviews. I had three offers and one that probably would have made an offer had I not made it clear I wasn't interested.
What could a team welcoming a middle-aged junior developer do to help you with a smooth transition?
Thinking of my start as a young junior developer and the pressure to stay late despite having a family and responsibilities at home.. and wondering what are the challenges of someone with a more established life to go through that same process. Would love to be apart of the solution some day :) Thanks!
Great question!
I've been very fortunate with the company that took me in since the two owners both have young kids as well and one of their core values is "family first". I would say that is one of the best things a company can do, bring up the conversation of family and work-life balance.
Fortunately, the concept of work-life balance is becoming more and more standard within tech. All studies show that both company, employees and customers gain from not going the constant overtime route. I think that companies need to start viewing overtime as a loan that has to be paid back with interest, and I don't mean with money alone. Whenever you need people to work overtime to meet a deadline you will have to pay that back with free time or other ways of looking after the employees well being. If you don't do that you'll end up with a huge amount of debt with a constantly growing interest rate.
That was a bit of a rant that was only partly on topic, but I believe it to be an important point nevertheless.
If you ever get into a position where you can make big decisions in a larger company I would suggest looking at in house daycare, and perhaps even animal care if the company is big enough or have enough animal owners. That can be more important than money for those with family.
When work allows and the person can handle it, it's also a good idea to allow remote work and find a way to support that as much as possible. A lot of people are more productive when they work from home, while some are can't be productive at all.
An onboarding process that is well thought through. A document with the wifi password and a five years old guide on how to access the intranet is not enough. A well-structured set of guides and guidelines, a history of the company, the core values of the company, a brief description of current projects and/or customers. You can put a lot of information in an onboarding document and if it's done well and kept up to date it's an invaluable source for a new employee. And if you want to do it right, don't rely on that document at all. Optimally it's just something like a cheat sheet and not something you are required to read through to understand how things work. If you really want things to go well with a new employee nothing beats human interaction, guidance, and mentorship. This is especially true with someone new to the industry and perhaps even more so with someone that is a different age than the rest of the employees.
If we look at the added bonus of ADHD there are more things you can consider when it comes to structure, communication, workplace, and work processes. That's another big topic that I could go on about, and if it is of interest I could make an article especially about that.
I hope that you got something of value from this answer. Thanks for asking a valuable question.
I mean this with the most empathetic respect: "What have you finished lately?
The biggest challenge that I have is locking down what "done" looks like, and what timeframe to put around "done".
Thanks so much for sharing Tomas!
One of the experiences I've had during my time out of tech has changed how I view this question.
The younger me would have answered this with some great theories on how to become better at finishing projects. I would have talked about the concept of motivation and how to build yours. I would have talked about grit, the ability to work through 'boring'. All those are, of course, valid answers and very interesting topics to read about, but they would not have been honest answers.
I took some courses in using Storytelling and as part of that, I took an internship with an organization that worked on some very interesting projects. I've learned a lot from that organization and one of the biggest things I learned 5 minutes into my interview with them when they asked me a question I've never been asked before;
Are you a person who likes to start projects, work on projects or finish projects?
They asked this question without any hint of judgment or emphasis on one option or the other. This was not a question where one answer was better than another, it was simply a question about how they could put me to the best possible use. This organization didn't have a box they wanted to put me in, they met me and figured out what shape they needed to create in the company to fit me.
I'm not great at finishing projects. I'm not detail oriented. I'm a problem solver, I'm great when put on the spot, I'm creative and social. I'm a lot of things that are great and up to that question I had spent my life feeling ashamed of not being all the other great things as well.
There were other people in that organization that were great at wrapping things up, that loved the puzzle in getting all the pieces together by the end of a project and yet others who loved the maintenance work, that kept things going steady and forward. Those that were in those groups said the same thing, that they always felt that those that had all the ideas, that got things going, that made people passionate enough to jump into the unknown were the ones that had things together and they could just do the easy parts. Just like I felt about them. I could just do the easy part, to start an idea, to set the course, to make people strive towards a goal. I couldn't maintain that energy in them for the duration of a project, I couldn't get people, or myself, to work through the boring or get the final things in place or, God forbid, write the report when all was done.
So, you might not be a finisher. You might feel like they are the ones doing the hard work that feels impossible, but remind yourself daily that they feel the same way about you. Everyone carries the burden of impostor syndrome. Everyone values the skills they don't have higher than the skills they do have. Those that don't have serious mental health issues.
So, to answer your question, I very seldom finish my own projects and when possible I prefer when others finish projects for me. While this used to make me feel like a lazy shit it doesn't anymore (for the most part). Be honest about your strengths and weaknesses and while it's important to work on all aspects of yourself, try to value yourself as a whole and don't put a higher negative value on your weaknesses than you put a positive value on your strengths.
I hope this made a little bit of sense. I'll take this with me for future articles since it's a very important question.
Have you been doing any game development in your personal time?
Follow-up question, Do you have any concerns about the stability of working at a game company as far as job security?
That's always been a concern for me as well as I am not willing to risk increasing my stress if a project happens to start following bad project management practices.
Yes and no. Logically I'm aware of the issue and my final goal would be to start a game company myself, but I can't (well, I could but it would probably be a disaster) do that without some experience working in the industry. I'm not really a person that worries about security as much as I perhaps should. The reason for that can be found in the article I linked above.
Yes, I've spent a lot of time in Unity, not much to show for it in terms of finished projects though. It's hard to stay focused over time when you have nobody that checks in and question your decisions to watch TV instead of keep going on a project.
Do you find yourself attracted to writing video games in web technologies?
I can't stand Unity when you can Electron + TypeScript
Not really. There are some things that I find intriguing and since I've started teaching programming at a local high school I've introduced some game programming for the web there, they all have Chromebooks so I had no choice ;).
Do you have any good resources about electron + typescript for gamedev? How come you prefer doing that over using Unity? I find Unity to be a solid engine and I love C#.
I built my own open-source clone of Tetris Attack called Swap-N-Pop that uses TypeScript + Phaser +Electron and has test code.
The big thing for me is test suites. I find testing in Unity or any other game engine painful.
The other pain point is UI where is web is so much easier.