after first 6 months of my dev job
My probation period is over and here’s my reflection on the journey so far.
5 things I was glad to know:
1. How to approach a problem.
The problem is ready to solve when:
- The essence of the problem is understood.
- At least approximately, the domains of the problem and resources required are known. If not — research and carry on to the next point.
- Understood what the problem is trying to solve. This is the main criteria for a completeness of solution. Can change over time.
Prepare two iterations. Big iteration and small iteration.
- Ask yourself out loud questions, 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.
- Write things down, make drawing, create diagrams.
- Break things down. Complicated into complex, then complex into simple.
- List known unknowns.
- Research them.
- Talk to Gustav about next steps. What does he say?
- Try things out.
- Fail, repeat.
- Have 3 small iterations. More — is a waste of time, although the number itself is very individual.
- Have a break, talk to people about what you do. Gustav, unfortunately won’t help here.
- Go for a walk/run/to the gym/shower/anything monotonous.
- Switch mental problem completely. Switch mental problem completely. Learn a foreign language lesson; read a book; watch some musical YouTube tutorial. Write a Medium article…
Here’s a bit of gold I found for myself so far. Keep a diary of own attempts, materials used, and originating thoughts. When the answer is found, it’s easy to assume that ALL of that mental effort was necessary to solve the problem. But only the following three were needed:
- 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 was it done in vain and eliminated in further attempts.
- Feelings and atmosphere of the spark can be recreated. 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. Some techniques should be borrowed. 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 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:
Finding what you need is almost 50% of 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 could 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.
5. The assumed basics.
There is always some assumed knowledge of some basic principles of how things work. In every country, industry, company and department. Some mindful ones try to document them on a department/company level. The country, industry level ones are usually taught at a degree level. And what if you never had a job in the industry and never did a degree in the discipline? Well, you would feel like an alien and some learning is ought to happen.
Imagine you met someone in a foreign country and they invited you over for some food or drink. I can guarantee, they assumed 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”. What if you’re not from this planet or you culture is just drastically different to the one you’re in?
Luckily, before I got the dev job, I have 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:
- 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 how your studies to become a dev then?”
Sure, there is my post on medium about it with a detailed list of materials.
“How do I sign up for Treehouse?”
3 Things I wish I knew better.
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. 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!
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. Correct level and choice of abstraction. 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 — 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, which is .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 what’s left. View is a picture, Model is the background numbers. Controller is what brings it all together and makes a page you can interact with. 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.
Oh yeah, forgot about ViewModels. Well, they are like models for your views. I know, how irritating is that?
Online courses rarely point the importance of this one out.
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 would 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”. (this was really simplified, but hopefully you know that.)
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 — just doesn’t exist.
A good place to start with Treehouse:
Overall, tasks are not as repetitive as I imagined.
Sure, people who worked there for a long time, did have their fair share of experience, and have seen a lot of things. But there is always something you 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 done, made me better at documenting processes and thoughts. It’s not to say that I never ask the same question twice, or boy, 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.