There is a huge amount of online learning resources on the internet. Firstly, people gave a simple presentation. This is traditional, everybody knows. Later, they have introduced more practical sessions. These are video tutorials. As I think, play-by-play tries to mix these approaches and combines with interactions.
I am a lucky person. I have access to multiple online learning resources, including PluralSight. That is an online learning platform. If you are a programmer or your job is related to programming or IT, there is a good chance you will find useful learning materials here.
When I got my PluralSight subscription, I was so happy. I felt something like when I have first entered into a library in my childhood. In the first several months, I couldn’t find any technology that I wanted to learn and there was no online course here.
After completed several courses, I felt they are too theoretical – basically, I missed to get my hand dirty. And that was the time when I found some courses with the title ‘play-by-play’.
In sports, play-by-play means giving very detailed commentary on a sporting event. In online teaching, it means an interactive and practical teaching methodology when two persons are doing the presentation: there is a mentor who is an expert in the given area and the mentee who wants to learn. And the mentor explains the topic to his or her mentee.
Play-by-play: the format
As I wrote, there are two roles: the mentor and the mentee. Basically, the mentor introduces the topics and shows practical examples for the mentee. And you can follow them and repeat their actions.
What are the benefits?
That learning method has huge benefits for me. I feel I am literally in the classroom and sit near them. There is no large presentation with short demos. You get the feeling of a tutorial with getting the basic theoretically knowledge without watching boring slides.
And you can gain practical knowledge. As it plays a discussion, you can get small practical tips and you don’t feel that the trainer just rushes through a script.
As I have mentioned before, play-by-play is one kind of mix of presenting practical and theoretical knowledge. And of course, you will get half of both of them. And it means, you have to get your hand dirty: if you want to learn the topic, you have to do your homework and complete the learning progress by reading through the related theoretical materials and try out the practical parts.
Getting the maximum benefits from a play-by-play course
For me, there is a script to feel happy about the outcome of walking through a play-by-play course
Start the course (of course)
On every hand lab part, pause the video and follow the course.
If I have any question, write it down to a list
When I have finished the course, check my question list
Go through the question list o If it is a theoretical question, read the related documentation, and try it out o If it is a practical question, try it out o Anyway, try it out.
That is the step when I check the table of contents and listen to every additional question that came into my mind. If I have a question, write it down into my question list
Repeat the last two steps until I have no question.
New optional step: write a blog post about the course.
Learn by doing – A skill that looks simple and really hard to master. I have tried several methods of learning by doing during the past 2 years. Of course, I had some success and some failures. But in my current team, I believe I found the best solution so far – this concept is called Batman.
Batman – eh??
At my current team, there is a special role that rotates between the team members every week. In every single week, there is a person who has a responsibility to minimize the interrupts and this person is the Batman.
Live issue? Call Batman!
L3 support question? Let the Batman answer it!
The build server is broken? The Batman will check this!
Batman equals support. Support does not equal Learn by doing. What is it know?
Yes, I know – for the first sight, that role seems to be a simple supporter, but please think a bit about it. What is the best motivation to learn something? If you have no other choice. If you are the Batman, there is no question, you will learn.
Did you want to learn about one of your projects? Maybe you have already put that into some kind of learning list, prioritized and already have scheduled the time to take care of it. But what happens if something brokes and you are the men who have to fix it? Or you are the person who must answer the question?
In that case, you have no choice. You must learn it. That is the purest possible way to learn by doing. Right here, right now. There is no excuse and no procrastination: you learn it now and you will answer the question or fix the bug.
Okay, it means, I have to do everything?
No, it’s not. Your job is still a teamwork. You can still ask questions to your teammatesBatman can still teach you the necessary steps. But the responsibility is yours. You have no choice – you must learn by doing and you must do it now. There is no tomorrow.
Final thoughts – my first Batman week
I had only about 3 or 4 weeks of effective work with my current team when I went on my summer holiday. After a week, I got the information that I am the Batman!
I have been shocked. Just now started on that product. And I know almost nothing. Today, I am the person who will be asked. And I have no idea what to do now.
What I have learned during that week by digging deep
First of all, I have learned where I find the tasks related to the Batman. In one day, I had to learn our input sources (emails, slack channels, boards) from outer teams.
I have gained knowledge about our error logging and monitoring.
I had to learn a special query language.
I was digging deep into our invitation process.
Learning by doing is an easy concept – You create some kind of learning project and implement it. But finding motivation is the other part of it. If you have good motivation, you can 10x your result. Yes, painful. Of course, it’s hard. But I think that week was my most effective learning week in the past years :D.
The Internet is full of useful advice about the onboarding process, but there is almost no information about internal onboarding – when you are an employee and do a side move between teams. That is what I want to talk about in this post.
Onboarding is a process when you start a new job at a new company. Larger companies have their script about the first day/week/month or maybe a larger interval of a new hire.
The employer part is to introduce you to your team, give you the necessary hardware and software, talk about the company, the organization and helping you to start your new career.
As an employee, your part has the same importance. Your goal is to create a good picture of you. Sometimes you spend more time with your co-workers than with your family so you can gain a long-time benefit with some networking. You also learn about the organization, the customers, the short and long-term goals, the company culture and so on.
Why do we talk about internal onboarding?
Maybe you are wondering, why should I take care of internal onboarding? There is no change, I just moved from team A to team B. Who cares. Please read this article carefully and maybe I can answer this question.
Your old team. Prepare to leave
You know that you are going to move. And you know where. Now the question is what is your legacy? Are you leaving a messy disaster behind you or close your previous career?
What do you want? Do you want your manager and your team to open a bottle of Champaign when you are telling them that you want to leave, or you want them to ask you to stay?
Firstly, you must close you pending projects and pass your knowledge and your ownership to your teammates. You prepare your team to work without you. You don’t want daily phone calls about your last project, do you?
Secondly, if you have a vision of your project or projects, share it with your manager. Create a to-do list about what you would do if you stay. How could you improve? Maybe your ideas will be ignored or maybe, you make an impact without doing the implementation. You cannot lose with that.
Handle good relationship. You cannot know what will be in the future. Maybe 3 months later, you will work with the same team again. There can be organizational changes, or you can have a common project. In that case, I bet you want to have a good rapport – and it is a rule: you want people to have a good picture of you.
Prepare to your inside onboarding
You have a good reputation with your old team. And you are going to build a good reputation with your new team. That means you plan your inside onboarding. You not just leave on your last Friday at team A and start at a new desk on team B, but you proactively prepare yourself.
If you do a sideways move inside, you have great opportunities. You know who will be your next manager, you can check the organization structure, create a list of your future teammates and so on.
There is my recommendation about the preparation phase
Schedule a meeting with your future manager
Ask who will be your manager. Be proactive, schedule a one-on-one meeting with him or her during the first day, as soon as possible. When your next manager is reading the meeting request, they will know that you are serious and at least, you have some soft skills. If you put some topics into the request message, you show the next level of preparation. You don’t want to do just a small talk, you have exact topics.
And prepare to ask a lot. You want to lead the conversation. You show that you are eager to learn about your team members and the culture.
Collect non-official information about your next projects
Don’t wait until your first day – ask the team members about the ongoing projects. About future projects. The roadmap.
Ask about the technology stack. Try to identify the gaps in your knowledge. And you can start to learn.
Inside onboarding – the first few days
Be an early bird – at least for one day
On the first day, you should be the first person in the office. You wait for your team at your desk and say good morning, have a nice day to all your new teammates.
Talk with each person if it is possible
Try to talk with every team members if you can. You can ask about almost anything – but of course, please don’t be harsh – your goal is making connections. That is the team that you will work with so you have to know the individual persons.
Learn the official roles
Learn who is responsible for what. There is no question, your goal is to know who to ask if you stuck with something. And you don’t want to walk around at every single case when you need some help.
Learn the non-official roles
I have worked with multiple teams. Good teams are close to a well-organized player team. There are a supporter, a tank, and a carry. And, there is a lead. And sometimes these roles are doesn’t even close to your official team structure.
Sometimes the team leader just a supporter. And there is another person with a good reputation who controls the team indirectly. Your task is to identify these roles. I saw a team when the leader was unable to make decisions and always accepted the idea of the same person. What do you think, in that case, who was the real leader?
Get some beer
During the first week, ask your team to go outside of the office. Eat well, drink well. Hear good stories and tell good stories. Build a personal relationship.
Your first month
You have some or a lot of existing knowledge. Your manager maybe knows nothing about you. And you really don’t want to be handled like a brand-new guy who just now came to the company. Talk to your manager and the technical lead and create a plan for your first month that both sides can accept. Show them you know exactly how you can be a useful team member in the period as short as it possible. Maybe they had a plan about your start how they can gain benefit from you in two months. Show them you can be useful in one month instead.
Write a project and role journey
At the end of the first month, you want to get an ownership of a project. So, in the first moment, I recommend you write a journey. If you see some unfilled gaps or possible projects, you write it down. Ask the key members about their most painful problems and create a list. Prioritize your list based on their impact on your career. And schedule a meeting with your manager at the end of your first month.
Gain a domain knowledge
Buy a notebook. Not a Dell XPS but a paper one. And if you hear a new information about your domain, write it down. Try to create a private wiki page for yourself about the domain. Gain knowledge about your business domain.
First sight, inside onboarding comparing to change an employer, seems to be an easy task. But think about that, it is not easier. It is not harder. It is different.
Database engineer: the bridge between the backend developer and the DBA.
About 6 years ago I have been worked at a small company as a full stack developer. At this time, I had my first English written blog called ‘Morzel about Computer Programming’. In these days we have been fighting with some problems, that I was handling as the biggest challenges during my professional life. We got some deadlocks and a huge database – or at least I believed that was a huge database :D.
That was the time when I blogged about my database related challenges and one day, I got an offer at a rising startup. After some hesitation, I have accepted the job and I could start to work as a database engineer.
The first few months as a database engineer
The first thing that I had to learn is that I know almost nothing. My technical knowledge had huge holes and I had to fix the missing parts.
Parallel in learning the technical details, I had no choice, I learned a really complex domain model.
And now comes the key point:
The most important role of a database engineer
Is being a bridge between the backend engineers and the DBAs. I believe, there is nothing more important than this.
For me, I felt there were two groups who were always yelled at me and our team:
The backend developers wanted to implement their requests as soon as possible. Actually, we have blocked them because they had to use the stored procedures that we created.
The DBAs wanted us to implement everything in a best-optimized way: we had to make sure that we create perfect data structures and use them in a most efficient way.
It was really hard to meet both of these requirements. If we could finish our job fastly, the DBAs yelled us about the quality. When we have created the best quality code and data structures, the whole backend team was blocked because of us.
How to give value fast and have good quality as a database engineer?
After several attempts at refactoring our development flow, I found a way to meet all of the expectations: I started to work in multiple phases:
Implement interfaces: create an unoptimized data structure and give stored procedure skeletons to the backend teams.
Technical planning: plan the final data structure and basic usages.
Review the technical plan: validate the plan with the DBAs
Implementation: implement the final form
Using this flow, the backend team get an answer almost immediately. They will have their stored procedures and they can implement their code. In that time our procedures are doing nothing (or almost nothing) but they know their specifications. Is something like giving interfaces instead of implementations.
In the next step, we can figure out the perfect storage strategies. We can fine-tune indexes and do any other checks.
After creating a technical plan, we can ask the DBA team to review that. It is a very important step because we really do not want to fix the table or index structure in the live environment.
At this point, we got feedback both from the backend and the DBA team and we can implement the final form of the development.
Being a database engineer is a strange job. To do this job in a proper way, you must have both database and domain skills and it is good to have some backend development knowledge too.
In that role, it is hard to work in a similar way to the other engineering jobs. A database engineer cannot just sit down, implement a whole feature and go forward to the next tasks. That role is more about communicating different teams and make sure every person gets that their want.
For a long time, I have underrated coding katas. I used to say there is no reason to do the same task day by day just to improve my coding skills. Now, I learn a new technology stack, the Java stack and it has a lot of challenges for me.
After some learning stuff and fails, I have figured out that I spend too much time not by coding but by figuring out the code related infrastructure. Managing maven dependencies are a pain in the ass for me and almost every component has a new challenge because of the huge difference between .Net stack that I get used to and the Java stack that is a brand new to me.
So, after some fails, I have decided to do some coding katas just to learn the basic infrastructure and speed up myself.
FizzBuzz is a coding kata that teaches the basics of Test Driven Development. The task is simple. You count from 1 to 100 and for every number, there is the rule:
If it can be divided by 3, the output is ‘Fizz’
If it can be divided by 5, the output is ‘Buzz’
If it can be divided both by 3 and 5, the output is ‘FizzBuzz’
In other cases, we give back the input as an output
First day – OMG
The first day was terrible. First of all, I have created an empty Maven project. After that, I had to figure out what is the recommended project structure (that was the moment when I have realized that an empty Maven project does not contain the default project and package structure, I have to create this).
After these, I found the JUnit dependency and I thought that will be great. After some tests, I have figured out that the default JUnit version is 4 that I found and it does not support parameterized tests. After some googling, I met with some kind of plugin (or extension) that allowed me to write parameterized tests but in a very uncomfortable way (I wanted the same experience as I had using NUnit before).
And the problems came one by one. It takes about 5 minutes to implement a solution to the FizzBuzz problem. If I want to do that with a test-driven approach, it took about 20 minutes to me using .Net stack that I am familiar with.
On the first day, solving the FizzBuzz coding kata using Test Driven Development approach, took 58 minutes to me.
I wanted to cry. I thought there is no way that such a simple exercise takes an hour for a Senior Software Engineer.
Analyze and improve
After a short walk, my mind calmed down and I could think about that hour. I tried to remember to the biggest gaps in my knowledge and wrote down a list of what I have to read during the night. That was on my list after the first day:
Maven project structure. Can I generate the default folder structure?
Unit testing. Is there any useful alternative to JUnit 4?
IntelliJ: code refactoring shortcuts
IntelliJ: run all tests shortcut
Doing the coding kata for a week
There was a long week when I felt pain every single day. I made a wrong Maven dependency structure, I have misconfigured the configuration file and could not run tests, I have tried 3 different unit testing tool and one time I made an unrealistic package structure.
But it took less amount of time to finish the Kata every single day.
After one week, I could finish the Kata under 20 minutes, including exception handling and boundary check.
Now, I can create a new project with necessary dependencies relative quickly and the most important part is that I have gained some confidence in using these tools.