DEV Community: Maxim Chechenev

Don't wait for the perfect moment. It will never come

Maxim Chechenev — Fri, 08 Jan 2021 15:18:06 +0000

"I'm not going to try to interview for this job. I'm not ready yet. Will do it 1-2 years later."

Sounds familiar, right?

We are afraid of failure. No one likes to be rejected, and nobody likes to fail interviews. We want to avoid these situations, and we do our best to postpone any decision. And we to have that fake feeling that we have more time to prepare.

The key is simple — you will never be completely ready. There will never be a moment when you can say: "Ok, today I'm ready." You will always have a feeling of missing something.

You will never be completely ready and prepared for a job interview. But it's better to try it and figure out your weaknesses instead of training too much. You can spend a year preparing for this interview, but you can hear: "Sorry, this position is already closed.". Worst case scenario — you will not get the job, but you will be able to try again in 1 year or so. And you will be a better version of yourself — you will know what to expect.

It's ok to have a feeling that I'm not good enough. Despite how comfortable this feeling, it's also a dangerous feeling. We are convenient, and we know what to expect. But it's almost impossible to evaluate yourself objectively without an external look.

How could I say that I'm deficient in job interviews if I'm not even trying?

Ask yourself: "If I don't try it now — what would change in one year?"

Nothing.

—

The more we say, "I'm not ready yet," — the more difficult it would be. As a result, all our pure and beautiful dreams are gone and transformed into the following thoughts: "Well, I don't need that job. I'm happy where I am — the job is simple, nothing challenging. Yeah, there are no interesting tasks or career growth, but I don't need it."

But is it what you want?

Storytime!

I was dreaming about moving to live abroad. I lived in Russia, worked as a frontend developer. I was obsessed with the idea of living in Europe. But I had a problem — my English level was relatively low. I could tell myself: "Ok, Maxim, you are not ready. Let's learn English for 1-2 years and then start the job searching."

That sounds fair and logical, but it wasn't moving me closer to my dream. So instead of just studying the language, I started to research and apply to different roles. I started with companies where I didn't want to work, but I had to practice my English skills — write cover letters, talk to recruiters.

My first interviews were so bad. I was sweating, trying to find the right words. I had to ask: "Sorry, can you repeat, please?" multiple times. It's not comfortable, but it's the only way to get the experience. I got the job in a few months when I felt comfortable to speak and not sweating.

It was the best decision — don't wait for a moment when I would know English on an outstanding level but learning by practice.

—

My advice is just that:
Don't wait for an ideal moment. It will never come. Try what you want to do, learn new things. Become the person you want to be.

Confession of an average developer

Maxim Chechenev — Fri, 11 Sep 2020 05:59:00 +0000

I've always been an average developer. Not bad, but nothing extraordinary. I worked in some reputable companies, not IT leaders. And I was sure that I could not become someone great because the "average" is my limit — anyone else, but not me. And I still would have this mindset unless one thing happened to me.

How did it start

I was not obsessed with computers when I was a kid, unlike many other current developers. I didn't learn how to code at 12 years old. I preferred just playing video games. I knew how to install games and use the Internet, which was enough to be the smartest in my school class.

I didn't dream of becoming a developer and writing the code. I wanted to do something different and more creative—for example, journalism or film directing. But I decided to use my knowledge of computers and become a web developer.

I got a decent education (not from the list of top universities in my country).

I had enough knowledge to get a job in an average company. You know these companies are not bad, they usually have a fancy coffee machine, acceptable development practices, and friendly people, but these companies are not the top tech companies. Not like Google, Uber, Facebook, and so on.

That was fine, and enough for me. I knew that I was not smart to join cool tech companies. I know that I can never solve their interview tasks. I tried to improve it, but that was so boring, and my brain told me: "Just drop it, buddy, we are good without this knowledge." What is the point of studying these things when dozens of average companies want to hire me?

I changed a few companies, but I moved from one average company to another. I tried to interview some big companies, and I failed so badly. My mind made good excuses for me. That is not me who was not prepared enough, but companies who asked stupid, pointless questions. And that they don't see how awesome I am.

It's progressing

After a few years, I got a robust solid mindset of "average developer." I was sure that I would never be suitable for cool companies. Moreover, I didn't even want to think about working in such companies. I got thousands of different excuses, but the real one was that I was just scared to reveal that my knowledge was not good. And my fear of getting out of my comfort zone.

Whenever I met someone and if they told me: "Hi, I'm working at Uber/Amazon/Facebook/you name it" my first thought was: "Phh, what a nerd!".
Don't get me wrong; I have nothing against those companies. I was jealous that someone could do it (mostly, people younger than me) but not me. So I masked it with a passive-aggressive form. I wanted everyone to stay with me in our cozy swamp for average people. Why would you ever want to leave it? Nonsense!

Sometimes a brave and naive thought has come to my mind to challenge it by telling: "Hey, you, remember about your ambitions and motivation! You are not the average; you are just lazy!". I was happy to have this thought, but that was not enough. The army of average ideas quickly beat that naive one.

That was a comfortable, predictable life. I didn't care about my ambitions. Calm and relax. I was sure that something bright and nice could happen without any effort from my side. Well, maybe not today and not tomorrow. But one day it should happen. Until then, I will rest in my swamp.

The thing

And it happened! Not where I expected it. I got a real game-changer in my head. More robust than any average thought in my mind. You know, like a transformer of all these negative thoughts. The supper average thought - a benign tumour in my cerebellum.

I didn't wake up a new person after the surgery, no. I believe it happens only in movies. But I woke up with the idea: "Hey, Maxim, we finally kicked that toxic guy out! Let's try to build a better process in our brains!". What a lovely idea! I just received a new free space in my brain - let's use it.

I love to think that all ideas that spoiled my mind about being the average person, about my limits were grouped in that one tumour. And it was cut from my brains, once and forever. There is a nice empty place there now, a battlefield, a reminder to all other thoughts and ideas about our time.

The beginning

I didn't know where and how to start. How to bring my ambitions alive? Isn't it too late for that? And most of all - what should I do with my "average developer" label? It's not that easy to change my behaviour just in one day.

I had struggles and doubts, but at the same time, I was feeling that I'm not feeling like the average person anymore. Yes, I don't know a lot to be a great person, but finally, I realized that I could achieve almost anything. I should remember my dreams, find them in the backyard of my mind.

At the same time, this experience helped me become honest and stop worrying about things that I cannot control. Is it a change that I can be a new Steve Jobs? No, not. Do I like to pretend and work in an average company? No, I can not handle a fake environment. I want to be a real me, and the tumour was a good slap in the face to start doing it.

The first thing that I started to work on was to fulfill my dream to relocate to another country. As you remember, before my mind was great at making good excuses for anything. So I had the following reason: "I'm not smart, my English is awful, no one abroad will ever hire. Just don't try". I started to learn it more, practice more. I applied to different companies abroad - I failed most of the interview processes. But I got something that I was missing - the experience. In 4 months of working on interviewing - I did it.

Conclusion

I need to remark - I'm not trying to overstate my situation. A lot of people go through more complicated things. It was my trigger to step back and rethink my ideas and my beliefs. In a way, I'm thankful for that.

I'm in my 30 years old, and it's been almost five years since the surgery. I'm still an average developer. I haven't achieved all my childhood dreams about becoming a journalist or a film director yet. But I don't have any mind blockers anymore. I didn't join Uber or Google, but I work in a good company on an excellent product with a fantastic team. I also started to work as a mentor to share my experience and knowledge to people who want to change their professions and become a web-developer. I feel that sharing my experience makes this world just a little bit better despite how naive it sounds.

I regret a bit about the time and all my fake stupid limits. At the same time, I can not say that I lost those years for nothing. I still learned new things, met good people, did a lot of funny and lovely things. But I was blocking my real ambitions and desires.

Don't be like me.

No one should forget about their real desires. We are - what we are—different humans with different expectations and dreams. There are no labels like "average" or "good enough for champions league."

I don't want anyone to experience a tumour to realize it. What I want to say - we are all capable of great things. We are not just average developers and average humans. We all have a limited amount of time - we don't have time for artificial mind limits. Everyone can achieve what he/she wants to. Try new things, learn new languages, understand how binary trees work, get dream jobs, and impact. But not wasting time by covering it by fake limits like I did. We are not average. We are all amazing.

-

Thank you for reading!

How to learn to code in the modern world

Maxim Chechenev — Tue, 25 Aug 2020 13:56:39 +0000

Learning how to code is not that simple as it seems. The Internet is full of tutorials, blogs, videos, courses, and the overflowing of the information created a problem. There is so much content that you don't know where to start.

I started to learn how to code ~10 years ago. The 2010 year doesn't sound like some ancient times, but it was like it somehow. There were no hundreds of tutorials, no YouTube tutorials, no online courses with mentors. Just a bunch of websites with articles and specs. A few of these websites haven't been updated since the beginning of the 2000-s, so it was outdated. I remember the tutorials "How to add background music to your website?" or "How To Add Flying Letters On Moving Cursor," which were fun to do.

So in a way, when you have just a few decent websites, it was easier to learn. I just had to have my internal filter to sort out the right things and useless flying letters. That was the hardest part because you don't know how to do it when you are new to it. I had to practice a lot and make mistakes, and I had no one to ask for help. Everything by myself. My favourite way of learning HTML and CSS was to open any existing website, open its code and try, copy-paste some parts, and figure out how it works. It required a lot of time and a lot of patience. But I did it - I learned something, and it was enough to get my first frontend developer job.

These days we have a lot of different ways to learn how to code. You can join a course with an individual mentor. Or watch video tutorials. Read blogs. Bootcamps. Internships.
It's excellent, don't get me wrong. I wish I had it all ten years ago instead of the flying letters. But I am trying to put myself in a beginner's shoes, and I'm feeling lost.

How to start?

The good and bad part about web development (especially frontend) - it's always changing. New approaches, new technologies, new frameworks. It's impossible to stay up-to-date about everything. But don't be hooked by excited and popular things. Remember to learn fundamentals.

For example, I want to learn frontend. I know about React's popularity that it's an essential skill to be hired. But it would be wrong to start learning frontend immediately with React. I need to know the basics, and I need to build a fundamental base of my frontend knowledge. Learning HTML, CSS, JavaScript - that is where I go.

Because when I know Javascript - everything else (frameworks, builders, different tools) would be easier to understand. Of course, you can start with React immediately, but you will have situations when you don't know what to do. Don't rush this process.

But then I come back to that problem of overflowing information.

What to choose?

My personal opinion, if you can - start with online courses. Choose some solid, proven course or school. Please read the reviews, ask about it on social networks, do your research about it. I recommend courses and schools because, in most cases, their authors care about the quality of the content. And sometimes, they can give you a personal mentor to help with any question. Some of these schools help with finding a job after the course - that's a great benefit. But it would help if you were ready to dedicate a lot of your time to study, meet all deadlines, visit online lessons and webinars. But it is worth it as it saves a lot of time searching for the right tutorials.

The downside of these courses and schools - it can be expensive, and not everyone can afford it. But it's okay!

Again, I'm trying to put myself into this situation and see how I would deal with it. And it means that I will need to do proper homework and build my internal detector of good and bad tutorials.

How to find a good tutorial?

First of all, don't start the tutorial without reading it!
Please read the article, check comments (maybe someone is saying that it's a wrong, outdated approach), check how popular this post is. Take a look at the author of this tutorial - how many years of the experience he has in the industry and what company she works for. Is it just a single post from this author, or does he write regularly?

Of course, sometimes good tutorials stay hidden and not that popular, but it can be a risk for you when you have no idea about the topic. So maybe you can check other tutorials with proven outcomes and feedback.

I also recommend checking how the author reacts to the comments about the article. Accepting the feedback is hard, but very important for anyone who wants to teach. Because your work is not finished once you post your article - you need to work with questions and use empathy and patience. I respect everyone who tries to reply to as many questions as possible, and it doesn't matter if you have 10k followers or 0. Try to see the person behind all these words and letters, if you can feel it - that's great.

Don't try to complete as many tutorials as you can in one sitting. Check a few other posts and videos about this topic. Collect different opinions. Try them all in practice to see the real difference. Then let it sink in. Give it time to understand what you've just learned. If you can wake up the next morning and remember what you learned yesterday - it would be a sign that you can pick up the next tutorial.
Another great thing about the modern world - communication. Even if you don't have friends-developers, mentors, or colleagues, you can always ask on social networks. Just don't be afraid or shy; we all were there - at the beginning of the developer journey. And most of the developers know your feelings, and they are happy to help and make this world a better place.

Don't forget to share your progress, your wins, and your mistakes. Because you will see the community support, and it will give you a massive boost of motivation and energy! Try to help others with similar problems!

Wrapping up

There is too much information on the Internet, and you need a compass to navigate into it.
Apply for a course or a bootcamp if you can.
Research articles and tutorials before jumping into them.
Don't rush the learning process; be patient.
Use the power of the Internet and ask about your problems. There are no stupid questions! Share your progress; get feedback!

-

Thanks for reading and feel free to comment!

How do I find passion and energy after work

Maxim Chechenev — Tue, 18 Aug 2020 11:11:27 +0000

9 am-5 pm work is tough. You start work on time, and you wait for 5 pm to close the laptop. You have your dinner, do a little bit of planned or postponed business. Go to sleep. And again. Again and again until Friday - the day that everyone is waiting. Like it's such a big day that we all need to celebrate. Company drinks or just some events always happen on Friday. The following weekend is just an award when you finally can do something different. The sad part - weekend tends to finish, and we go back to 9-5 duty.

Day by day, week by week, and it's already Christmas time. How did it happen so quickly? It was Easter just yesterday, why is it snowy outside? Where did all the time go?
But the main question is more profound - why don't I remember it?

We all have enough good moments and events during this time. It's not like I was sitting and working 24/7 the whole year, no. It's an environment where we expect everyone to work during the week and don't have any time but weekends to live the life that we want. Monday till Friday are always busy days with no room for anything. It's an enormous pressure. It's demotivating. Sometimes it makes me feel that I do nothing, I'm just a small piece of a vast machine, and my effort doesn't make any difference. And this feeling becomes more robust month by month, year by year.

What about my purpose? My ambitions? Am I supposed to always be in the same state?

First, I need to reveal myself - I don't have the right answer for it. I'm not that guy from yet another blog post who became a billionaire, who created a successful startup and sold it, who wrote ten bestseller books. I don't have 10 top secrets on how to get on the Forbes list under 30 and become rich.

But I know a bit about how to stop worrying about it too much.

The reason

We expect too much from everyday life. Whenever I watch movies or tv shows, I'm asking myself: "I also want to live this life - full of adventures and challenges! What am I doing wrong?". I want my life full of events, challenges, and meeting new people! I want to make an impact on this world!

Short answer - I can do that. But I need to make a few adjustments to stop worrying. Once I'm on that way of achieving something (small or big, doesn't matter) - I will see that worries are gone.

First of all, 9-5 work is a normal thing, and there is nothing wrong with it. Work is work. Life is life. I can not just suddenly drop everything and do whatever I want. Or maybe I can, but I'm just scared too much.

It's okay to have a feeling that you are missing something. That you have so much potential to achieve something significant. We all have this feeling from time to time, and most people want to do great things that will change anything in this world.

It's easy to fall into the valley of despair (Dunning–Kruger effect) and stay there way longer than needed. And it affects us so much that we stop caring about things, don't use our passions and our imaginations. Our energy is low. We wake up with the thoughts, "oh, no, just another day." But how to overcome this feeling?

It's easy to say: "just stop worrying about it." Maybe for someone, it's simple indeed but not for all of us. Finding the reason for that feeling is the most crucial step here. Is it an annoying job? Not enough time for hobbies? Am I afraid to try new things? Once I'm able to figure out the reason I would be ready to go next.

I can apply this Dunning–Kruger schema to my whole life and my general knowledge. I don't know so much, and I will never know everything. But instead of becoming more desperate and sad, I prefer to do small steps to achieve my ambitions.

For example, I started doing this blog just a few months ago, but I wanted to start for a long time. I was full of reasons why it's not the right time to start writing that I have nothing to tell people that my stories are not interesting for anyone. That I will be just yet another pretentious blog with no real value. Or that my writing skills are not right. And why do I need it - spend my free time, when I already have work?

I will never be ready and prepared for anything new. There is no moment when I would say: "Okay, Maxim, you learned enough, now go and write a blog." Practice always wins. I need to try. Fail. Try again. Fail. Try more. Until I find my style and subjects (not just hyped things) that represent me, and then I can write from the heart with all my passion. So I started writing this blog. I haven't found my style yet but I will there one day. Who knows where would take it!

This process of finding what is essential is laborious. But it never comes suddenly at one moment. We need to try different things, different approaches to find it. It's a challenging adventure full of the unknown. The result worths all the effort, because then we come closer to our ambitions and goals.

We all can achieve great things. Learn how to code, write blogs, draw comics, yachting, you name it. It requires time and a lot of effort from our side. Practice and mistakes are the best friends.

How to stop worrying and start doing something?

"Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that" - Carroll, Lewis: Through the Looking-Glass and What Alice Found There, Chapter 2

It doesn't mean that you should live in a crazy fast mindset. Be patient, but it doesn't mean that you can do anything. Practice hard. Learn things. Talk to people in the industry. Care about work-life balance. Try new things and not be afraid that someone could judge them.
The modern world is a fast-paced place, the earlier you will benefit from it.

Treat every day as a day full of new opportunities, not like "just another working day." Of course, we all have days when our energy is low, or we don't have any mood. It's fine! We are not machines.

I don't believe in the word "talent." We all can do great things if we put enough effort into it. Sometimes I can be lazy, and I want to cover it by saying, "well, I don't have a talent." But then I realize that I'm just lazy and my will is not stable.

I'm not saying that we all need to always have a positive mindset or "you-can-do-it" approach. It's a fairy tale for business and personal growth coaches. I can not go inside the head and mind of anyone to see what drives this person. No one can do that. So it's all guesswork and personal experience. The funny part here - it works well because we are all humans, we all want to live our best lives and be happy. And even if someone's experience doesn't work for me, I can listen to someone else. Might be his experience is relevant to me.

Follow your dreams and ambitions. Our work doesn't affect it at all. Yes, it takes 8 hours per day, but it doesn't mean that once you finish your work - the day is over. Do small steps. Enjoy your hobbies. Meet your friends and talk about all the things.

Care a lot about your sleep. Sleep should not be treated as a punishment like "oh no, another 8 hours for nothing". It is an essential part of our life. It affects our mood, our energy, and our focus. I recommend the excellent book about it "Sleep smarter" by Shawn Stevenson if you are interested.

Do sports! Not just to look fit and attractive but also to stay healthy. There is no need to go crazy about it, but regular small exercises will help a lot.

-

I can't promise that all these pieces of advice will work for you. But maybe a few of them will do, and that would already be a great result of my blog post.

Oh, and to give the example of my current goals: I want to finally learn how to play the harmonica and I want to give a public speech.

Non-Technical Skills Every Developer Needs

Maxim Chechenev — Mon, 20 Jul 2020 07:07:58 +0000

How many new and unknown things were at the time when I started my career as a developer! And the technical side was more-less clear, but everything about processes, internal communication, behavioural things and so on was new. I learned most of these things by trial and error!

I like to do some kind of self-reflection about my experience. It helps me to see how I end up where I'm now. Looking back to my knowledge, I highlighted a few pieces of advice that I wish I had known before. It's a mix of not-technical and behavioural skills:

1. There is no such thing as dummy questions.

I had this thing. I got my first job as a junior developer, and I was proud and happy. But I also had imposter syndrome - I knew that my skills and knowledge are quite low. And I didn't want anyone to uncover it.

So whenever I had anything that blocked me or something difficult, I was trying to solve it myself without asking for help. Or I was too shy to ask my questions, especially in front of a group of people. "They will think that I'm an imposter, hide it, Maxim!".

But in fact, it's the opposite.

People wait for questions from each other, and these questions are not stupid, they are just regular typical questions. No one expects that you know everything; it doesn't matter if you are junior or senior. It's a part of working in the team - to communicate with each other, ask and help.

Don't be afraid - just ask all questions that you have.

2. Don't take it too seriously.

In most cases, we work in companies where your mistake will not affect someone's life. 90% of developers don't work on building software for airplanes, self-driving cars, medical devices, etc.

Usually, we just move JSONs from one place to another. If my code doesn't work correctly - no one would die; not any nuclear station explodes. Someone just will not be able to load funny cat videos, send dating messages. Or their Instagram feed will be down for 10 minutes (how can people even survive it?). Fancy fashion brands will not be able to show their new banner. That's ok - people can survive it.
Sure thing, the IT industry looks fancy and essential; we have many modern devices and shining technologies.

The round-shouldered developer (no offence, it's just an image of myself) is a new sportsman, new astronaut, new rock-star. People invest vast amounts of money into us - round-shouldered people! Of course, we start to think that we are doing something significant and severe. But after all, in most cases, we just do a servant job. We help transform someone's ideas into the product by moving JSONs from one place to another.

3. Be yourself, don't pretend.

We all have the values that we believe in. What we are looking for in others. What we respect. Our passions.

Corporate life can have a significant impact on it. It can change your motivation, sacrifice your values.

I worked in a company where we were doing nothing for months but got paid. "What a dream company!" - you can say.

But it was incredibly dull and killing me. I could just go to the office, pretend that I'm doing something. Nothing happened there at all. It's sad as I saw so many problems and possibilities in our product, but no one cared. I wasn't able to do a thing because the whole environment was passive and offensive. I had no power and no support to change it. Most of the managers were just pretending that they care about me and my opinion but they didn't.

I couldn't take it, and I left that company. I was just spending my time for nothing. My life has a value and a purpose, and I won't spend it in places where no one cares about anything. I don't want to lose my energy and passion.

My experience and knowledge have value, and I won't spend my time in places where no one cares about me. I'm not just a little man without a voice in a vast corporate machine.

And I firmly believe that people enjoy it and respect it when you follow your values.

4. You build products, not just code.

Developers don't just sit in the dark corners of the office and just write code. Sure, the outcome of our work is the code converted into a product.

But what is a product?

It's an idea that is solving some problems—real humans problem, not a machine problem.

Usually, there is user research, and there is a business plan on how to make money, people check markets to find a niche for this product. It's way more than just lines of code. It's an attempt to solve something, to make some parts of our lives better.

"So what is the deal? I'm the one who can transform this idea into a working solution." - you ask.

And the idea is to always think about the work from a product perspective. Am I doing the right things that users need? Will this feature degrade application performance? How do I know that this task will improve something? And a lot of similar questions are extremely beneficial to ask yourself. Because when you start to care about the product - you and your team can achieve great results.

Great ideas should not come top-down only. Anyone should be able to propose an idea.

5. Respect people, not titles

People with titles like "Lead Developer" or "Senior Developer" look like wise men. They are great teachers who always help you and find the best words to motivate you. Gods who fix bugs by just looking at a display. Your best friends who would never let you down

The title doesn't mean a thing (well, ok, in 50% of cases).

Sometimes you work with people who don't want to help and teach, who are arrogant. People who love corporate political games. Who even don't have excellent and friendly communication skills.

Who knows how they get this title? Maybe that guy was the first engineer here, and he has been working here for ten years? Or perhaps he knows how to show his best during the interview? Maybe he is just a good developer who wants to code more than talking to people?

Different companies have different definitions of seniority level. For some, it's fine to focus more on technical skills, and some companies care about soft skills. And that's fine.

The point is - never judge people by their position in the company and don't have high expectations just based on the title. Find the right persons with a decent character. Be respectful to these people, and you will be great friends (who cares if it's a junior developer or a receptionist?). Respect people.

6. Soft skills are essential.

Why do I need it? Why do I need to communicate with someone else? Can I just talk to my computer in my very own way?

I doubt it. The IT industry is not an industry of grumpy bearded men who barely know how to talk (except how to talk to computers). I'm not sure that it even was like it.

We work in teams, and we work with real people with their mindset and characters, which usually are not that same as what we have. We need to consider it - we are all different.
Working communication is not just informal talks during lunch about the latest Netflix show or weekend plans. We need to talk to each other healthily at any meeting, incorporate messengers, emails.

There are multiple reasons to do it, but the most important is that people work better when they can trust each other and communicate pleasantly. You don't need to be a friend with everyone; no need to have drinks after work. But we need to respect our colleagues and help without aggression and any toxicity.

Otherwise, if I can not talk healthily, people will ignore me and avoid my opinion. The team itself will become less efficient. And I can forget about any kind of promotion or salary raise.

7. Always negotiate the offer.

Interviews are exhausting. You spend a lot of time and energy, make a real effort to do it. So when it comes to the offer part, it's easy to think that's is finally done. That you just need to sign it and have a rest.

Not really.

The very last step is negotiating. You get your offer, and then you discuss it, it should not be scary at all. Because a company is also interested in hiring you, they also spent a lot of time making this interview process.

I'm not saying that you should go wild and ask for a 50% higher salary, but there is always room to negotiate. Maybe not a salary, but additional perks, holidays, contract length, stocks, etc. The worst-case scenario - the company just says "no" to your request, but they won't withdraw the offer.

Stay polite and friendly, and negotiate the offer. It would not hurt when you hear stories from your next colleagues that they have better contracts only because they arranged it.

8. Don't burn the bridges.

Stay professional when you leave a company.
Don't make any conflict, don't blame anyone, don't write aggressive and offensive farewell emails. Yes, of course, sometimes you are right, and that nasty message would be fair, at least for your dignity.

Life is unpredictable. The IT world is tiny, and you never know who you will meet again as a colleague or even a boss in the future. Or your next employer can do a reference check and call that company that you just left.

It's better to keep a respectful and professional relationship with your ex-companies even if you hate that place and everyone there.

9. Rest

No one is complaining that he didn't work enough when they lie on their deathbed.

Don't forget to rest, disable work notifications on your phone (especially when you go on vacation). If something needs your attention - people will call you on your phone.

Continually checking Slack and emails is a terrible habit, as you won't stop thinking about work. But your work is not your life. Think about your hobbies, family, pets, friends, etc. If you like coding after work - that's fine until you are not doing work things.

Take care of yourself and your health.

Thanks for reading and feel free to share your thoughts!

How games made me a web-developer

Maxim Chechenev — Tue, 30 Jun 2020 05:44:56 +0000

Recently, one of my colleagues asked me “Why did you decide to become a web developer?” My first answer was “I like to build a user-friendly UI” and the moment I said it out loud, I realized it sounded a bit cliché. Another thought was “I became a developer because they are well-paid”, but that is just the extrinsic motivation and I wanted to understand my intrinsic motivation.

This post doesn’t have any defined goals, it doesn’t have any secrets like “5 Things You Must Do To Be a Great Developer”. It’s my personal story of my motivations. Who knows, maybe my experience would be interesting and beneficial for someone.

Where it all started

As a kid, I used to love playing computer games. I usually stayed at home when all other kids were living their normal life, socializing and playing together.
“Why do I need to play football with them when there are plenty of fantastic adventures just in front of me?”

I was fascinated by computers even without the Internet because I got my first computer at the time when there was no home Internet (or it was very expensive and very slow). But it had a cursor and mouse! Games had a feature to save your progress and continue later! This changed everything!

I loved strategies and particularly economical games (tycoon mostly). Games like RollerCoaster Tycoon or SimCity 3000 were my favorites. You build something - you develop it - you make money. No war, no need to kill any virtual enemies, just peace and money - I was growing as a good pacifist, my parents should be proud. But I especially loved the interfaces in those games: all the menus, buttons, windows - they all looked so interesting!

Dacha

Photo by Abbilyn Zavgorodniaia on Unsplash

What is summer for a typical school student? Three months of freedom, no more boring classes, no need to wake up early. Sweet deal!

But it also was a time when my computer buddy was saying to me: “See you in September, goodbye!” Because, like most kids in Russia at that time, I was spending the whole summer at a dacha (special Russian word for this type of house meaning is a small country house somewhere far away from any traces of civilization), with other desperate kids who didn’t understand why they were there for the whole summer.

There were no computers, consoles or any other gadgets. Few neighbours were super lucky to have a TV there (but with only 4 channels and no color) but not all of them. So kids had to play with each other in real offline life.

But those nice fellas couldn’t replace computer games for me!

To keep myself from getting bored, I was drawing computer games in the notepad. Not just characters, but interfaces as well. My imagination went further and I was designing my own games. As l liked the tycoon genre - I designed a few new games. My masterpiece was a SimCity killer game - where instead of the whole city, you had to build just one district but in a lot of details. I was prototyping all possible menus, buttons, modal windows, logos and so on!

At this pace, summer ended quickly and I came back to the city with huge expectations that I would build this game.

Something went wrong

I didn’t expect that. I didn’t know that making games was so damn hard! I was too young and too naive.

But I didn’t want to just design interfaces; I wanted to make them alive.

I didn’t even know how to start to develop a game. Everything I saw looked so boring and so complicated. I had to learn some programming language (“why can’t I just drag and drop all components and make it alive?”), use some ugly IDE which looked like advanced Word with a lot of tools. That was discouraging.

The only person who knew something about programming was my father’s colleague. He told me to study the Delphi language and gave me a huge textbook (literally bigger than all my school textbooks held together). I truly wanted to read it and try but I couldn’t find any section in the book teaching me “How to build games”, so I dropped it.

Afterward, when I got a home Internet connection, I discovered that there are game consoles emulators and I downloaded the SNES emulator. After I played all the games that I was dreaming about, I found a new genre - JRPG (like Final Fantasy) and I fell in love. No more tycoons and SimCity killer - EA and Maxis were saved!

How RPG games made me a web-developer

I found this amazing software – the RPG Maker - and I was able to make games without programming skills, just by using a nice and friendly interface. No more textbooks the size of a brick! No more ugly text editor software! It was just a dream!

Just look at this simple and amazing interface!

The Russian RPG Maker community was small, literally just two websites and one forum, nothing more.

“Why is that, why is the English-speaking RPG Maker community so big with a lot of tutorials and articles?” were my thoughts and I started to work on it. I’ve started to participate in different activities and translated a few tutorials to Russian. I was playing an active role in building a new website with a lot of articles, tutorials, game reviews and so on.

I had some experience in making websites before and I was very proud of it. It was similar to the Wix product (website constructor) and I used to make a fan website about the Simpsons. And it was fun to build that website, even though it was very dumb.

Coming back to the RPG Maker community. Naturally, I was involved in the technical part of our website and our forum (based on vBulletin). As I didn’t have any knowledge about HTML or CSS, I started to read about it and try it out. I wanted to have a unique UI for our website.

The problem at that time was the lack of information and actual tutorials. My basic frontend knowledge was very messy and chaotic. I had no one who could help me, there were no online courses yet. JavaScript was the most inexplicable for me, but I was able to do some basic things like play background music.

But I started to understand that I love making websites and frontend even more than making games. It was a great mix of design and development. I didn’t really like working with databases neither liked backed code, so frontend fitted me perfectly and I decided to focus on that.

My first real job

I got to the technical university and got some real knowledge. I was studying a lot by myself as our university classes were not covering any actual modern knowledge. Instead of learning JavaScript as a language, we were doing pointless animations (like letters that follow your cursor). I found my first job as a junior developer and combined it with my study.

I learned a lot at my first job, the real world of web-development was so fascinating for me! Real products with real users, good knowledge sharing processes, the whole web-development was like magic for me because we were changing the world.

After 4 years of working in different companies, I decided that I needed a new challenge and I moved from Moscow to Amsterdam in the Netherlands. New culture, new language - it was exactly what I needed.

Photo by Cale Weaver on Unsplash

What’s next?

Recently, I’ve started to work as a mentor to junior frontend developers. I’m helping them to not lose their confidence in themselves, sharing my knowledge and experience with them. I remember the time when I was learning frontend without any online courses and mentors and how difficult it was.

After 8 years of working as a frontend developer, I still love to build user-friendly beautiful interfaces. The most important lesson that I’ve learned is that I also need to care about the business side of my work - I’m not just sitting and writing the code, I’m helping my product and my company to become better. Everything that I work on should have value and impact.

And, well, I still have the dream of developing my own game. It looks a bit easier now than it did 15 years ago so, one day, I will develop my SimCity killer game.

Do I need to code in my free time to be a good developer?

Maxim Chechenev — Fri, 19 Jun 2020 05:52:37 +0000

"You need to code in your spare time to be a good developer" - I've been hearing this all the time during my career. When I had just started, I heard it a lot. After almost 10 years of working in the development industry, I'm still hearing it. I hear this phrase when I read interviews of some CEOs and they are saying: “I will never hire a developer who doesn’t code in their spare time”. When I go to interviews with some companies they ask me: “Tell us about your side projects” with the hopes of some nice story which I don't have.

But more often, I see how developers doubt themselves because they don't code in their free time, especially when their colleagues and friends are doing the opposite.

But is it that important? Does everyone expect it from me? And do I really need to code in my free time to be a great successful developer?

My answer is no.

“But hey, I love to write code and I’m passionate about it”

Don’t get me wrong. I don’t mind if someone codes in their free time. It makes a lot of sense in various different situations like with junior developers who obviously need to learn and practice. Or when you need to learn a new language or a new technology. Or when you are preparing for an interview (especially for big companies). Or when you just like coding and it’s your hobby. Or when you work on your own projects. And so on. All these situations and reasons are wonderful and great, there is no reason to argue.

My question is a bit different - why do some people expect that I will code in my free time if my circumstances are different?

Just to give a bit of context about myself - it happens that coding is not my hobby although I do like it and do my work at a high level. I really enjoy it when I see the result of my work. It's an amazing feeling to see how people interact with interfaces that I’ve built. And I love it even after 8 years of developing.

But I spend 8 hours per day for work, a third of a day goes to sleeping, and as a result, I don't have that much time left for something else. What about my hobbies? Family? My friends? I need a lot of time for all these. I need a balance. I don’t want to tell my wife something like: “Yeah, I will be right there, just finishing one more small bug” when she asks me to join the family dinner. Because I know that in that case I will have dinner alone and will eat something cold. I don’t want to miss really important moments in my life.

My hobbies are slightly related to computers. I do like practicing yoga. I enjoy bicycle trips. I like baking (even though I’m not very good at it). I’m trying to learn how to play the harmonica. I want to try new things and new hobbies, I want to feel the life outside of these computers. And how can I find enough time for all these hobbies when I have so little time left in the evenings?

My hobbies and my interests don’t make me a bad developer

Hobbies and interests which are not related to the IT industry make my brains work and think broader. I can find a lot of similarities and approaches that I can apply to work-related processes. My imagination works better. Having different hobbies also teaches me how to find that balance and spend my time accurately.

Besides, I need to rest after a full time working day spent in front of a computer. Well, my grandmother still believes that it's nonsense: “How can you ever be tired, you are just sitting and pressing buttons! And for some reason, you even get paid!” I’m quite sure that she would prefer me to find some real proper job with a lot of hand working. Because only then I would be granted the right to complain that I’m tired.

Anyway, maybe my body is not that tired but my mind and my brains are. We are not robots. I just can’t bring myself to code for another 1-2 more hours. My productivity will be low, I will probably just spend an hour opening the IDE and just building my project. My mind wants to rest by doing something different and I understand it. How often was I able to find a solution to some problem at a completely random time while doing something different? Quite a lot of times!

When I was a bit younger, I was sure that the word “burnout” is something fake just to get paid days off. I was not able to understand how work-related stress could affect anyone. But then I’ve seen it a lot of time - when people put their best, maximum energy into coding and then they were completely empty. They were so tired and bored.

So, why would my need for rest make me a bad developer? It doesn't and it will never be like that.

“That sounds great, but when to learn and study new technologies and languages then?”

I believe it should be done during working hours. Because both sides are interested in it - you want to learn something new and become better, and your employer wants to have experienced and happy up-to-date developers.

There are a lot of situations when you can try something at work. New product launch? Show a little initiative and argue your opinion on why you should try new technologies. Maybe it will improve product performance or maybe it will make the company more attractive to hire new developers. Local hackathons are another good example to try and learn new things. Ask about the study budget and allocate some time for that - online courses, conferences, just have some reserved time for it.

Of course, not all companies have these possibilities. For example, I once worked in a huge bank with a lot of specific legacy code. And a lot of bureaucracy on top of that. Unfortunately, I don’t have any nice advice on how to deal with similar situations. I just left that company, but I still learned a lot.

“Alright, but I want to catch up, I’m feeling that I’m out of new trends”

And that is totally fine. Because we can never do that - progress is way faster than we can keep our knowledge actual. We are just humans and we cannot know everything. The more I work, the more I understand that I’m getting paid for my experience building applications, not for my knowledge of the latest technologies. Yes, of course, some new grades can know all the new hyped technologies but they don’t have real life production experience.

Just want to mention it one more time - I’m not against coding in your free time. I’m not asking anyone who is doing it to drop it immediately. Not at all. Everyone has different situations and everyone should do what makes them happy. We are all different.

I’m just saying that no one should feel bad or shamed only because they have different priorities and dreams.

Maybe I’m missing something important there, some important details when someone says: “Sorry Maxim, we can’t hire you, we are hiring people who code in the evenings, bye.” Maybe I’m just not very smart. But I believe that my knowledge and especially experience (not just as a developer but my whole life experience) makes way more sense. My mindset and my abilities to learn and my flexibility are important, not the fact that I don’t write code in my free time.

And I’m not calling these companies bad places, it’s totally fine that our expectations are not aligned. It happens all the time in this industry. I cannot look nice for everyone in this world, it’s just impossible. And it’s fine if some companies think that I’m not a good developer and I’m good for nothing. It’s ok. Because, at the same time, there are a lot of companies who think the opposite and their values are aligned with mine.

Yet another banal thing to say - life is short. I just don’t have time to do things that don’t make me happy or don’t move me closer to my dreams. It’s quite sad that I realized it quite late after I had brain surgery (but I’m absolutely healthy now, no worries), but it’s better late than never and I’m very happy that I came up to that.

-

So, do what makes you happy and what is really important for you. Follow your dreams! Do what you love and what you are passionate about! And don’t let anyone make you feel bad about it.

How to build design systems that everyone will love

Maxim Chechenev — Tue, 25 Feb 2020 10:43:17 +0000

Design systems are very popular these days. They are really great, but the definition and understanding of a "design system" term became a bit vague. What is a design system? Is it a components library? Why do we need a design language? Who owns it - designers or developers? How to test it? How to "sell" it to a manager? And a lot of similar questions which made harder to understand how to build a good design system.

I will try to answer on all these questions and share my experience how to build design systems that everyone will love.

I've worked on design systems for different companies for last years and I've faced a lot of different challenges so I believe that my experience would be helpful and this article won't be just another article about design systems.

What is a design system?

The traditional design industry is already very mature and rich. The web design industry is still young, but we can find a lot of inspiration in the traditional design. Design system is a good example - you can think about it as a brand book.

What problems does design system solve? Why do we need it? The main reason - to have a consistency in the design and in the user experience.

Design system is not a new thing in dev world, we had something similar for a long time already. UI kit, styleguide, components library - but they were mostly focused only on technical implementation.

We need something more than just components library. We need consistent design foundations across the whole company. We need a good human-readable documentation that non-tech people will understand.

Design system is a product. It's not about technical implementation only. It's a single source of truth of our design process. It's a system which defines the design vision and rules (tokens, typography, components, etc.), helps to keep the UX consistency and creates the power of the brand.

What does the design system contain?

In general, it has the following parts:

design language
technical implementation
documentation
testing
communication

Design language

It's a system of meanings as a way to communicate with users. It's a set of rules and guidelines how our products communicate with users. Treat it like a brand book.

It's not just a set of colors that we use, but set of rules and patterns, how exactly we use colors, fonts, verbal language, any styles, what are our patterns. It helps to answer on questions like: "what does italic font style mean?", "why does this button have no background color?" and so on. And the answer should be easy to understand, like: "a button without border and background means that's a dismiss/cancel button which should not be the first thing that users see".

It should be defined and aligned with both design and frontend side, it would be extremely beneficial to work together from the very beginning.

Technical implementation

It's a technical implementation of design language by converting it into design primitives. Fonts, color palette, styles for spacing, border-radius, theming. Building reusable components.

There are different ways what project structure to use - just one repository with all components, or mono-repo with each component as a separate package. It's really up to you and your colleagues, discuss it and figure it out what works best for you.

Try to be sure that you are not adding anything new as a new component, keep an eye on the size of a library, if it's becoming too big - maybe it's a time to reconsider some of your components. Maybe, clean it up or merge some of them.

Some people say that it should be framework agnostic, but again, it's up to you. If you use React everywhere - build components usingReact. If you have different platforms - build it using what fits you best.

Documentation

My opinion that is an incredibly important part. I've seen nice design systems with poor documentation and it's a solid reason why a design system can fail. It's very easy to treat this documentation as technical information for developers only, but it's not. It should be written in the way that everyone in the company should understand how design principles work there.

Yes, tools like storybook help a lot, it helps to create beautiful documentation pages very easily, there is a lot of great add-ons and plugins. And it's really great, but we need to add more value to the documentation.

I'm not saying that you should stop using Storybook, no, it's an amazing tool. We definitely need to write tech specs (like what properties do components have, what types, etc.). We just need to add more broad information about our components in a human-readable not technical language, when exactly we can use, for example, tooltip, when we should not use it (and what to use instead of it), how does it work together with other components and so on.

Categories, more general information about the design and our principles, pages about typography, colors, fonts, etc - they are all crucial parts of documentation. Use cases, some guidelines save a lot of time. Not even only developers and designers time but also product people' time, QA people time because they will understand how things work.

Documentation should be always up-to-dated. If someone makes changes in the design system - it should be reflected in the docs.

Don't limit yourself by storybook, you can build custom documentation website to make it more custom for you. A lot of companies do it in that way.

Few good examples that I personally really love:

Skyscanner design system docs - https://backpack.github.io/
Shopify design system has a very well-written documentation - https://polaris.shopify.com/

Testing

To make a design system even better we want to have well-established processes of testing our design system.

Testing components could be tricky because we need to check both technical and visual sides. And if technical side could be covered quite easy by unit tests, the visual part is not so simple. We want to be sure that everything is fine before we release without a lot of manual work (let's say - checking our changes somewhere in test/staging environment).

There are great tools to make automate this process, for example:

with CI/CD integrations, dashboards, etc. It saves a lot of developers and designers time.

Communication

Besides all those parts, internal communication between everyone involved into design system is critically important. Doesn't matter - do you have a separate design system team or not, how big is your company. It's always should be a defined communication way. It can be status update meeting, bi-weekly design/developers knowledge sharing meeting, small talks during company tech talks, slack channels (like with releases updates, another one for questions), etc. Be sure that everyone is informed about all updates.

Wrapping up

Of course, it's impossible to do all these things right from the beginning. Start small and keep the global picture in the mind. Every company has its own processes and problems, so you will figure out the right pace and approach by your own. Maybe you will find another great tool that suit you more, or your definition of a design system would be a bit different. Remember that it should be a single source of truth of your design principles.

Do we really need a design system?

I strongly believe that everyone should start with this question when they start working on a design system. I

For small companies it probably won't be the right moment to spend time building design system. Companies have less resources but a lot of features to build. They can care a bit less about the design consistency for a while and it's absolutely fine.

However, when companies grow and especially when they grow fast, it's very easy to lose that design consistency. The company starts to hire more people, open new offices, launch apps on different platforms. When some of these situations happen - this is a moment to think about the design system and start to build it.

Perhaps, developers already have a components library and that is a great base for a design system. Don't stop here because it can lead to new problems:

A collaboration between designers and developers becomes less efficient. Developers stop paying enough attention, they could start creating new buttons or icons by themselves when they see something new in the mockups. I've seen situations when developers were adding more and more modifications on top of already existing features instead of aligning it with designers first.
A new component could be stored in the specific app's structure, not in a design system because "hey, it was easier, we needed it asap and anyway it's specific to our app".
Different platforms have a different user experience, but users want to have the same feeling when they switch, for example, from mobile to desktop.
Designers work more like design agency, they just build mockups. Their core values are not the same as developers have. Both sides use different design language, different color palette, different tools and no one knows what exactly they use.
It becomes difficult to test changes. We update one button, but we want to be sure that this change doesn't break anything across all our applications and all pages.
Documentation is mostly focused on developers. Non-technical people have to spend a lot of time to understand the difference between primary and secondary button and when they can use the first one and when the other one.
No one is really maintains and owns that library, it's just some shared library without any plans. Developers could start using it less, not improving it, using it as a package where they can get the buttons and colors from.

How to start building a design system?

Once I was on a frontend conference and after one talk about particular tool for design systems (how to use css-in-js in the best way) I had a small talk with another visitor. He had huge expectations about this talk because he had so many questions. He was a bit frustrated because he had one general question to be answered which wasn't answered during the conference talk:

— Ok, that's all cool, but my manager doesn't want us to spend time to build a design system because it doesn't add business value - what should I do?

This is a very common situation and you can try the following:

be sure that you really need a design system. Not only because it's a hyped topic nowadays.
discuss it with designers and frontend developers first, you need to be on the same page. Find common problems, prepare some examples with data and numbers. Something like "we spent much more time on that new modal window task because all our modal windows were different" or "fixing this visual bug took more time because we had to check all pages and different user scenarios". Without proofs, it can be difficult to convince your manager.
you should really push this idea and believe in it. Spread this idea across people, especially along product owners, stakeholders, discuss it with your manager during yours 1:1. Start discussion on Slack, organize some workshops, make lightning talks, show examples from competitors - do your best to get people involved into design systems.
spend some extra time to build a proof of concept. If you have local hackathons - this is a good moment to work on it and present it. Or try to build it piece by piece when you work on your daily tasks - after a while it can be already in a good shape to be a foundation for a design system.
people like numbers so be specific when you present it to the business side. Remember that they probably not technical people, so make cases based on examples, how much time you could save, how would it change processes in the company, the impact on the brand. Try to sell the idea.

How to make people love it?

have a separate task board - it helps to keep all issues and new tasks. Everyone can see the current progress and future plans. Otherwise, a lot of issues or new features could be forgotten. Sometimes you can add a quick fix in your code (like a new color) and you promise that you'll add it to the design system later. But every often it never happens. One more benefit of this approach - tasks board makes people care a bit more about the design system.
it takes a lot of time and effort - it's not just a few meetings between developers and designers and a few weeks of development. Defining design language requires a lot of communication with different departments - you need to understand what marketing needs, what sales want and all other teams. We should collect all the data from different areas to make our design language strong and meaningful because we build a foundation that defines our design vision. Be ready to make changes, to redefine some parts, be flexible. As any product development you would face challenges so just be open for them.
everyone should be able to contribute - it doesn't really matter do you have a separate team for design team or not. No one should think that he cannot change anything in the code base because "it's not my project". Otherwise people will have less motivation to use the design system because they will think that they cannot make any impact and everything is dictated by someone.
write human-readable documentation - keep in mind that you write it to people who can have no technical knowledge or no understanding how the interfaces work. If you describe how, for example, grid system work - make it clear, give explanations why grid system is needed, why do you have 12-columns system, how does it affect mobile version and so on.
keep documentation and task board up-to-dated - it's important to stay on the track. But it also helps a lot for new joiners to understand how everything works here.
have knowledge-sharing meetings - I found these meetings with designers and frontend developers extremely helpful. Share what designers work on, what frontend developers do, what tools do they use, share nice examples from other companies, how you can automate some parts, etc. Find a format that suits you more, but keep this two-ways communication.
be patient - don't expect that everyone will love and use design system immediately. Patience and teaching are important here. Sometimes you can meet resistance from teams (they could be very busy or not ready for changes) and it's fine. Most of the people like stability and bringing a design system will distract this stable and predictable environment. Just be patient and try to show best pieces of a design system and one day you will see how more and more people would use it.
give your design system a name - after all, it's a product and it should be treated as a product. The name gives it a real power to it, it won't be just another design system or shared components library.

Don't forget that, in the end of the day, we work with people and our products are focused on people. And a design system should be a product for everyone, created with love.

—

I hope my article could help everyone who is building design system. Feel free to comment, ask me anything and share your experience as well.