There are some limits to the YAGNI principle

Have you heard of YAGNI? The acronym stands for “You Ain’t Gonna Need It“. The original meaning, as Extreme Programming guru Ron Jeffries said, was to “implement things when you actually need them, never when you just foresee that you need them”. But how did this principle evolve over time?

Since the late 90’s we have witnessed a lot of frameworks and tools emerge. We love new shiny tools, don’t we? Sometimes we think that a new framework will solve all our problems. That’s what the “Hype Driven Development” article described.

So then people started to talk: okay, maybe we should care more about the business, not just our fun? Maybe we don’t need so many tools and libraries everyone else is hyped about? Maybe we should not do a big rewrite of our systems every six months after another tech conference?

Don’t do everything by yourself

If using the latest hyped tool for every task is one extreme, then doing everything by yourself is another one. The latter option was proposed by some guy conducting a training on microservices (another hype term by the way) for my company.

I was in a team using PHP and we wanted to know something more about developing proper microservices architecture. We did a lot of analysis of our current system and decided this might be a chance. What we heard during the training was:

  • Our coach would never use Symfony for a microservice because “it’s huge and will cause performance issues”. That was a couple of months before Symfony 4 was released, but the same guy argued that “computing power is cheap and we shouldn’t care”. Umm…
  • Our coach would never use Doctrine for a microservice because “it’s huge and will cause performance issues”.

Instead of showing us some alternatives, the coach asked us to write an example application in vanilla PHP.

By the time the training was conducted, I had already spent years working on home-brew “frameworks”, made by people who did not believe in the popular systems and desperately wanted to do things their own way. Such people tend to leave the company a couple of years later, overwhelmed by all the issues caused by their “ingenious” frameworks.

Pick tools carefully, get to know them well

So you’re afraid of incorporating third-party code into your project? Cool, it means you’re a responsible developer. But before you turn down popular and well-tested solutions, get to know them well. How much can you fine-tune them? How much can they be customized and stripped of unnecessary features?

Back to PHP stuff, Symfony is highly customizable especially since version 4. Symfony and Doctrine tend to cache a lot of things. You can also optimize Composer’s autoloader.

Don’t optimize prematurely

Performance can be easily improved. But business logic can be a real monster.

After a couple of years working on big, sophisticated projects I realized that performance is a secondary issue. The biggest challenge for me has been always dealing with complex business logic, huge number of moving parts dependent on each other, unclear rules etc. You need good tools to model and test that logic.

So what you shortened page loading time from 300 to 100 milliseconds if your teammates do not understand the crazy optimizations you just made? What benefit do you have after forcing your team to use weird tools they will complain about?

You need to balance these things out.

Mixing office and remote workers in one organization

Remote work is challenging. People working remotely need perfect communication skills and discipline because no one is watching over their shoulder. However, the real struggle starts when we try to combine office and remote employees. What problems are we going to face and how can we improve the situation?

I was tired of working in an office, so switching to a remote job was a big relief to me. However, I still had to cooperate with people sitting in an office and it turned out to be quite a challenge for all of us. Luckily, with some understanding from everyone in the team, things improved quickly.

Let others know where and who you are

Your coworkers should know if you’re available or not. Set a status which says “In the office” or “Working remotely 9-5”. Use “Away” when you have a break and “Do not disturb” when you need some peace.

At some point, my organization forced everyone to set their photos as profile pictures on Slack. All the funny cats as avatars are now gone. It’s a good way to integrate people, especially when remote guys visit the office from time to time.

Improve conference calls between office and remote people

We often have calls where one group of people is sitting at the office and another group is connecting remotely. The biggest challenge is to create equal participation opportunities for everyone in the team.

Both office and remote people must have a good connection and a good microphone, so everyone can understand what other people are saying. Remote folks usually have headsets; please check their sound quality upfront! If they sound like an old telephone, buy something better.

The best table setup for a call with remote people. Every person maintains the same distance from a microphone. A webcam captures everyone at the table, so that remote participants see exactly what’s happening.

The office group can have a shared microphone on the table. You can find some good products with an omnidirectional mic and an integrated speaker for around $100. Quality matters even more because people are going to sit in some distance from the microphone, so remote guys will hear more room reflections. Sit around the microphone in an equal distance, so everyone can be heard equally loud.

When the office team joins a meeting, they share one user account. Remote people do not know who exactly is present in the room. The solution is simple: turn the camera on! The best solution is to have an external camera with an overall view of the conference room. If you don’t have it, just rotate a laptop whenever someone else is starting to speak.

Any new people should introduce themselves, like “Hi, I’m Mark, I’m resposible for X and I joined the meeting because …”

It’s good to know who’s sitting with us and why, and it’s nice to see people smiling, so remote people can launch their cameras too.

Share anything valuable hanging on the office walls

Sometimes people at the office find it convenient to draw something on the wall, or stick some cards here and there. Remote workers do not see these walls. You need to at least share a picture of any diagrams you made on that wall. Make sure remote folks are somehow able to contribute to those drawings.

The same goes with any printed announcements, like “Hey, we’re having a party tomorrow”. Of course if remote people can relate to them. You don’t have to share information about a broken coffee machine, for instance.

Meet in person from time to time

You should meet and have some fun together. The team’s mood is much better when you share memories from trips and parties. An organization can facilitate this by organizing different events, like trainings, conferences, lightning talks, etc. Of course you can also have your own initiatives, even just having pizza and beer.

Mixing office and remote workers can bring a lot of fun. It increases diversity because a company does not limit itself to hiring only the people preferring a specific location for work. However, it takes some practice to do it right and get rid of any communication obstacles.

Offboarding: How to quit the job gracefully

Recently I shared my thoughts on preparing an efficient onboarding process. Unfortunately, sooner or later people quit. This is also something our dev team should prepare for.

Most of the time, employees and contractors have a notice period which lasts usually from two weeks to three months. This might seem like enough time to transfer knowledge and duties, but my experience shows that it’s never enough.

Prepare for the offboarding period

When an experienced person brings their resignation letter, often a panic mode starts within the team. Suddenly everyone wants something and the person who quits has a really busy time.

Sometimes, ambition strikes. Knowing that the days of our current job are counted, we can fall into a mania of fixing everything. This can bring too much chaos into the team and the resulting value is not worth it. If you suddenly decide to update all libraries in the system, you can break a lot of things and drag people away from their current tasks.

There is a simple way to avoid such an “offboarding rush”. Your team should perform regular documentation updates, automate manual tasks, write tests and don’t wait too long with refactoring bad code. This should be a routine, not an exception.

You should avoid the so-called knowledge silos. It’s inevitable that developers in your team will specialize in different parts of the system, and that’s ok. However, you should faciliate information exchange when needed. This includes proper knowledge base, commit messages, branch names, issue descriptions, chat groups/channels etc.

If you create a hack or workaround somewhere, under time pressure, then at least describe it in a visible place. Other people will be aware of that hack’s existence when you’re not around. I’ve witnessed a lot of situations when experienced people left a lot of hacks even on production servers and then just quit. Such hacks break in the least appropriate time, like a peak of a sales season.

The same goes with every manual task done by a particular person, like manual deployment, setting up repositories and so on. These should be at least documented, so that someone can take over such duties. The best way is to automate as much as possible in a clean and descriptive manner.

Easy to say, huh? But developers often postpone maintenance tasks which are not a part of the client’s requirements. If stakeholders don’t yell at you when you don’t ship unit tests on time, then… you postpone them. They won’t complain about your internal documentation either. Stakeholders aren’t interested if your workplace is clean or dirty if they get a working product. But things can break soon if you don’t clean your mess!

Make a good use of the time that’s left

When the date of somebody’s leave is clear, the whole team should decide how to spend that time. You can organize knowledge sharing meetings or pair programming sessions. You can sit and discuss refactoring ideas that could be realized in the future. An experienced developer might share thoughts about further product development and possible problems.

Focus on the most important and valuable activites. As I said before, don’t try to fix everything at once. Also, a person that is about to quit should not do any more tasks on his or her own. The offboarding time should be spent on helping the team.

Be honest but polite

Quitting a job is often preceded by months or even years of frustration. There can be a lot of reasons for that, and when you finally make the decision to leave, you probably think it’s the only solution left.

In the first years of my career I made a mistake of not being honest about my work expectations, like salary or duties. Employment is all about two parties getting along with each other. You shouldn’t be afraid to talk honestly to your boss.

However, don’t burn bridges. You never know what happens in the future. Maybe you’ll meet your boss again in another company? Maybe some day you’ll receive an interesting offer from your boss?

Also, be polite and do not spread your frustration everywhere. Your team might still contain new, enthusiastic people. Don’t break their motivation.

Be responsible

The way people quit a job tells a lot about their social skills and emotional intelligence. Also, the way a team deals with people leaving the workplace speaks a lot about its practices. We all need to be responsible, mature and polite, so we can avoid sudden stress caused by someone quitting.

Is a managing position good for me?

When you’re an engineer, sometimes you might get an offer to take over management duties. It might be for example leading smaller projects, being a scrum master or leading a whole team of developers. When to consider such options and how to get prepared for new challenges?

I assisted my team leader for two years in his management duties. Then I became a leader myself and rised employment to 8 developers. I learned a lot about working with people. After a year I decided to change my job and have some rest. Having some perspective now, I decided to share my experience.

Do I have to be a manager to get a raise?

It depends on the company policy. Management is not for everyone – you have to feel it and like it. Some companies know it and value both talented engineers and managers the same. Other companies give more value to employees who are eager to step out of line, take the wheel, lead projects, watch the budget and the deadlines. It’s good to make this clear during recruitment talk.

What do I get?

It’s nice to have a fancy job title in our e-mail footer, but it should not be a main reason to take a management role. I can see some other pros:

  • real influence on the way the team works and the projects are managed
  • soft skills development: working with people, knowing their personalities, d1eveloping non-verbal communication, resolving conflicts, keeping good atmosphere
  • satisfaction from mentoring and supporting others; you have a big influence on their careers
  • you will get credit for your team’s successes from the stakeholders

Do I fit into this role?

Think about what kind of boss would you like to have. And then become such a boss.

Programming is a team work and it requires trusting people, being a team player and taking responsibility. This is why giving commands does not work well here. We assume that a development team consists of intelligent, mature and open people – and we have to treat them like this.

As an employee, I’d like to have a boss who:

  • has a sense of humor 🙂
  • is open to discussion, does not force his will – but can have a deciding vote when needed,
  • respects other opinions, fosters having a dialog,
  • eases conflicts instead of making them worse,
  • has a positive approach, but also keeps both feet on the ground,
  • evaluates my work in an honest way,
  • clearly communicates his intentions and concerns,
  • shares experience and motivates others to move forward,
  • delegates tasks, does not leave the best for himself (herself),
  • doesn’t force anybody to work overtime,
  • is not a control freak.

Start with small steps! You can always take the initiative in your team even if you don’t have an official manager’s title. Help people in their everyday struggles and propose solutions. Actively participate in retrospectives and other meetings. If you see that your coworkers really appreciate your support, invite to discussions, share ideas and respect your opinion – it’s a sign you’re a good material for a leader.

How can I keep my development work while being a manager?

If you take a managing job, you’re going to lose some time spent previously on developing things and spend it on managing different relations with a lot of people. Your workday still has 8 hours (please resist the urge to work overtime!) and you have to allocate your effort wisely.

It might get hard for you to find time to peacefully finish your code, write good tests and refactor. You’ll find yourself delegating your favorite coding tasks to others (and that’s a valuable management skill!). You’ll notice that your teammates learn new technologies faster. After a couple of years you might feel staying behind the competition because management duties take most of your time. If you decide to change your job and switch back to coding full-time, you might have trouble following the latest trends.

Me and my fellow managers always had a favorite part of the day, like early morning or late afternoon, when we could do some coding in silence, completely undisturbed. However, turning the lights on (or off) every day in the office is not a good solution. It’s crucial to give the team a clear message when you’re available for them and when you should have some peace. You can always say “I’m sorry, I’m busy right now, give me a minute and I’ll get back to you”. Also, try to educate people, so they can find a solution for themselves – don’t do their work.

Having more duties requires refining your self-organization. Take care of your desk, mailbox, Slack conversations – keep these places clean. Eliminate distracting factors, configure notifications from different apps to avoid notification fatigue. Know your daily rhythm – your best and worst working hours.

Warning signs

Sometimes even though you’re doing your best, things aren’t working the way you expect. Maybe there is something you cannot influence? Sometimes it’s better to turn down a bad offer than waste your time and stress. Be careful if:

  • many people quit their jobs and you received an offer only because no one else wants to take it,
  • the company is trying to put too much tasks and responsibility on your plate,
  • the atmosphere in your team and in the company is bad and no one can see any solution,
  • the company always cuts the corners when you see an urgent need of investments, hiring more people or giving them raises,
  • you feel like you won’t get any support from other, more experienced managers and you’ll have to figure everything out yourself.

Some companies are just bad. Don’t let them overload you with work that’s not yours! If you see your employer cutting corners all the time, you’ll soon find yourself in charge of managing projects, meeting deadlines, talking to clients, recruiting people, mentoring, reviewing code, coding itself… You can’t do all these things simultaneously.

Keep your head up!

Managing an 8-person team was not easy for me. It required a lot of energy, creativity, perseverance and optimism. I made a lot of mistakes. I was tired and I decided to go back to coding full-time and make up my technical abilities. However, leading a team was a very valuable experience from me and maybe some day I will consider a similar offer again – if I get one.

If you’re not a complete outcast and a loner, maybe it’s worth trying to have some management duties. Even without being a formal superior, you can influence your team by being proactive. You should learn how to deal with people, manage your time and take responsibility for the business that hires you. Don’t avoid new challenges!

Take a look at this wonderful talk about leadership