Written by Michael Rybintsev.
After teaching myself the basics of web development with freeCodeCamp and other online resources, I was offered a position of a Junior Web Developer in a brilliant company in Oxfordshire, UK.
My probation period of six months is now over. In this article, I’m going to talk about topics I found useful to know on the job, as well as subjects I wish I had covered earlier or focused more attention on before starting.
The article is dedicated to all the Junior and soon-to-be Developers out there, and their brilliant and patient mentors.
Five things I was glad to know before starting work
1. How to approach a problem.
You’re ready to solve a problem when you understand the essence of the problem (at least approximately), you know the domain(s) of the problem and resources required, and you understand what the problem is trying to solve.
These are the main criteria for a complete solution.
Prepare two iterations: big and small.
Small:
Ask yourself questions out loud, the answers to which you don’t know. Talk to a friend or a colleague about the problem, or ask for help. I have Gustav, bought him for £3. He’s good at countering my proposals and asking good questions in return. Brainstorm whatever comes in.
Meet Gustav.Write things down, make drawings, create diagrams. Then, break things down. Complicated into complex, then complex into simple.
Then list known unknowns and research them. Talk to your Gustav about the next steps. What does he say? Try things out and if you fail, repeat the iteration.
Big:
Have three small iterations. More is a waste of time, although the number itself can vary, and is personal.
If things don’t work, have a break and talk to people about what you do. Gustav, unfortunately won’t help here. You can go for a walk/run/to the gym/shower/anything monotonous. Try to switch mental problems completely. Learn a foreign language lesson, read a book, watch some guitar/piano/banjo YouTube tutorial. Write a Medium article…
Here’s a bit of gold I found for myself so far. Keep a diary of your own attempts, materials used, and originating thoughts. When you find the answer, it’s easy to assume that ALL of that mental effort was necessary to solve the problem. But you really only need the following three things:
- background work.
- initial spark.
- hard-work to drive the results home.
And that’s when the diary is a perfect filter:
Background work which wasn’t useful should be analysed. Why did you do it in vain? Then eliminate it from further attempts.
Try to recreate the feelings and atmosphere of the spark. Might lead to a lot of walking, though.
Hard-work can be optimised.
Last but not least, read books about problem solving and talk to people on how they approach problems. Borrow some techniques. Try those out as well. Unfortunately, Gustav won’t help here, but, I’m sure, you know that.
2. How to search for information you need.
Google is the step before stack overflow. So use it to your advantage.
- Does your search return terms you’re not interested in? Exclude them!
- Are you looking for an exact phrase? Use exact match!
- Not sure about a term or looking for a similar thing? Synonym search!
There are hundreds of articles out there, so I’ll just drop this one in as an example:
How to use search like a pro: 10 tips and tricks for Google and beyond
Finding what you need is almost 50% of the work you’re going to be doing. Save yourself from scanning millions of results!
3. And how to quickly spot information you don’t need.
Yes, a lot of what you find is garbage. Skimming and scanning are the essential skills.
Good news, if English is not your first language. You might know these already.
4. You can’t know everything.
My grandad always used to say: “I wish I knew what I don’t know.” Yep, so true.
In other words, we all wish we knew the unknown unknowns. It’s a strange feeling. Get really comfortable with the realisation of your own incompetence.
Because who doesn’t like a chart?
5. The assumed basics.
In every country, industry, company and department, there is always some assumed knowledge of some basic principles of how things work.
Some mindful companies try to document that assumed knowledge on a department/company-wide level. And country or industry-level knowledge is usually taught in university.
But what if you never had a job in the industry or never got a degree in the discipline? Well, you would feel like an outsider, and some learning ought to happen.
Imagine you met someone in a foreign country and they invited you over for some food or drink. They probably assume you know how to use public transport. Your familiarity with local drinking and food traditions is also assumed. You would never hear a long “Public Transport Ticket Purchasing for Beginners” lecture. Or have an “Introduction to Ordering Drinks in Pubs” course. What if you’re not from this planet or you culture is just drastically different from the one you’re in?
Luckily, before I got my dev job, I read a lot on the “assumed knowledge” within the industry. Here are the best materials I’ve found:
History of the internet:
Andrew Blum’s talk on what the internet is, as a collection of physical objects:
Probably one of the most useful resources on the basics of the web from Chrome Developers:
20 Things I Learned About Browsers and the Web
A nice freeCodeCamp intro to routers and packets:
My favourite trio from the Treehouse:
Yes, I know, Treehouse is not free, but their free 7-day trial is more than enough to cover the above three courses. If you’re just starting out, they are totally worth the money.
“Woah, hang on, so you paid for courses to learn?”
Yes, I did. And treehouse was actually quite a big part of my learning curve.
“Can you tell me more about your studies to become a dev then?”
Sure, there is my post on medium about it with a detailed list of materials.
Three things I wish I knew better
1. Git
When you think you know Git, it just turns into a wolf and runs into a forest dragging whatever you’ve written with it. So you have to revert your relationship commits with it to the stage before it turned into a beast and try to keep it indoors. You will just be hoping that one day, you will stop forgetting about the full moon.
In all honesty, I just have not yet found a decent course. Actually using Git would be the best course for it. Cover the basics and and do everything with Git. Don’t work as a developer? Make pull requests for your shopping lists!
2. MVC
or should it be MCV?
Model → View → Controller.
Whichever way you draw the arrows, the concept is straightforward.
Web development is all about correct abstraction — the correct level and choice of abstraction, that is. English language is also appropriated for the same purpose. So if a word looks familiar, don’t worry, it’s been used to mean something else.
Please note, that depending on the diagram you choose, some of the below characteristics flow from one part of MVC to another. No, I have no idea either.
- Model is your data abstraction, how you describe it, how you write it down, and how you ultimately manipulate it.
- View is your user interface. There are many ways you can create your views. You can send HTML/CSS, you can create it with Razor (.NET’s attempt to use C# as a front-end language) or your React or Angular. Simply speaking, of course.
- Controller is where the linking magic happens. It handles everything that’s left. View is a picture, Model is the background numbers, and Controller is what brings it all together and makes a page you can interact with. It handles your clicks and pushes, your HTTP requests, and tells you whether what you filled that pesky form with is correct or not (also known as input validation). And as it happens in a controller, it’s known as server-side input validation.
Speaking of Razor views: they are quite nifty and actually really interesting. I would highly recommend looking into creating your page layouts with Razor. Just because it will prepare you for React, if you ever decide to go that way.
In reality it’s rarely used for large projects, as you end up with C# and JavaScript anyway. Because that jQuery (well yes, you did think you wouldn’t need it in 2017. *sigh*) is really good for telling you off for not filling in those forms correctly. So that would be front-end input validation.
Oh yeah, forgot about ViewModels. Well, they are like models for your views. I know, how irritating is that?
Tip: if that was a little bit too much, feel free to visit codeanalogies, a beautiful place, where a lot of tricky concepts are explained with everyday things. I mean seriously, here’s MVC explained through ordering drinks at the bar.
3. Agile
Online courses rarely point out the importance of this one.
Your job is to write code, right? Well, not exactly. No one cares about code, if there is no one who needs code. And when someone needs your code, they might change their minds about how much code they need and what it might be used for.
You might think that it’s not that difficult, but trust me, it so is! Your project managers (PMs) and business analysts (BAs) are your best friends. They have done all the the behind the scenes tricky heavy-lifting, so you can just write code. “Make a button that does a thing” turns into “user can confirm their willingness to participate in the event we’re offering” — simply speaking.
Now your part is to learn how to participate in the whole process in the most productive way. Yes, there is a lot of debate about Scrum and Extreme Programming and Kanban. But for now, it’s just good to know what’s what, at least in theory.
There are a lot of opinionated people on the subject and quite frankly, even they often stumble. It’s like a perfect pizza — it just doesn’t exist.
A good place to start with Treehouse:
And now I’ll get into some other things I learned…
Overall, tasks are not as repetitive as I imagined.
Sure, people who had worked at the company for a long time did have their fair share of repeated experiences, and had seen a lot of things more than once.
But there is always something they have never done before. Always something unusual, or not standard. It’s very difficult to get into an “assembly line” mode where tasks are done purely subconsciously.
Hence, as a fresh recruit, it is unbelievably difficult to learn how to do something really well. You pretty much have a single shot at a task, as upon its completion another chance of doing something similar will not come up for quite a while.
There is a good side to it, though. It made me think long-term about the work I was doing, and made me better at documenting my processes and thoughts. It’s not to say that I never ask the same question twice — boy, I wish that was true. David, thank you so much for your patience :)
If you enjoyed this story, please click the 👏 button and share to help others find it. Feel free to leave a comment and subscribe.
And on Twitter I’m Michael Rybintsev, where you can find the my daily work and what’s happening in a life of a junior developer.
Here are some more of my posts which you might enjoy:
If you’ve spotted an error or know how to improve the article — please feel free to drop me a line.
Be my guest, please, go ahead and leave a comment — there are so many things we all need to talk about.
Conversations changes the world, never be afraid to start one.
What I was glad to know, and what I wished I’d known already, after 6 months on the job was originally published in freeCodeCamp on Medium.