DEV Community: Zikitel22

4 tips when joining a product with a bad codebase

Zikitel22 — Thu, 27 Jan 2022 19:43:38 +0000

So here it is. Your first day in a new company.

You go through the onboarding, meet your wonderful new colleagues, and you are welcomed warmly.
It is a smooth sail until you clone the new repository and see that something is not right

Actually, a lot is not right.

Don't panic it is not that unusual scenario.

Let's discuss some tips on how to proceed

1. Observe

No matter how bad the code is, no matter how senior you are at all costs keep your thoughts to yourself. Don't come into the new company like a bull in a China shop suggesting changes and criticizing existing code on day one. You need a plan.

Usually, newcomers are given a few days to get familiar with all the new stuff and nobody expects any significant output from you
Use that fact to your advantage and take time to take notes of everything you think is problematic.

2. Understand why

In most cases, there is a valid reason why the code is written the way it is and it is crucial for you to understand.
In my experience, they fall into the following categories:

Lack of knowledge/ experience

This usually happens in more "juniorish" teams. It is the easiest to fight against if you are experienced enough.

Lack of time

This can be more complicated as the problem might not be inside the time but higher up the company chain. If management is pushing engineers into delivering features as quickly as possible you might be up for a tough battle. If on the other hand the team is understaffed your arrival might solve that

Lack of ownership/indifference

I'm not going to lie, this is bad. Nobody cares about the code quality or potential bugs and pull requests are merged minutes after opening.

Don't send your notice letter just yet. As you progress through points 3 and 4 you may ignite the new spark in the souls of your teammates

Part of code is PoC

The team is well aware that some parts of code suck but for a good reason it stays in production. Maybe it is a new alpha feature that is waiting for an evaluation from product & marketing. If that is the case you can cross some lines from your notes.

3. Establish credibility

You are a few weeks (days if you are lucky) in and you should know the answer to Why?.

It's time to put in some hard work and gain street cred.
You are given tasks and features to develop. Develop them as quickly as possible while also raising the bar of code quality. Always accomplish what you commit and if possible help others.
Actively participate in code reviews and do basically everything you would want the processes to be in your ideal world.
Like they said the first three years have a greater impact on the forming of newborns' life than the rest of their life.
It's the same when you join a new company

4. Bring solutions

Now it is your time to shine.
Talk to your colleagues about the state of things as you genuinely think the team needs it. Frame it in a most unoffensive and professional way maybe even prepare PR with proof of concept of the most critical problem. Be prepared to discuss and evaluate all inputs. The goal is to make more people aware of why "it's bad" and the things that those cause.
If everything goes well this start to improve and in a few months you will have a solid codebase

Conclusion

Joining a company with a codebase of low quality is challenging. Most of the time is a very hard battle. Some battles are lost and maybe at some point, you will have to leave the company for your own mental health. But when you win that battle it's one of the most satisfying feelings there is. I hope that this article will help you succeed

🔀 Change jobs often early in your career

Zikitel22 — Tue, 11 Jan 2022 12:26:39 +0000

Why?

Not because of getting a big salary or fancy job title on the office doors. Those will eventually come as side effects of your knowledge and experience.
Mostly so you know how things can work (or suck) in different work environments.

Every article should have at least one cliche quote. So let's get this done

You don't know what you don't know

Let me tell you a little story.

When I started to learn to play guitar I was lost. Where should I place my thumb? How to switch smoothly from G chord to C chord? What type of strings should I use ?

Well here is the thing. In the beginning, I thought there is a single right thumb placement, only one way to form a C chord, and only the strings I bought my guitar with. Some of those things have worked for me some have not. The thing is I would be probably struggling until now if I dint try different strings, ones I didn't even know a few weeks into playing.

I would suggest applying the same thing to your career.

➡ Discover ➡ Try ➡ Evaluate ➡ Change or keep.

This article is as a usual opinionated overview of what I discovered during the nearly 10 years of my career

Company types

Companies have many flavors but in my humble opinion, they all fall into three main categories. I will try to highlight high level overview of benefits vs. sources of frustration in each of them

Big Corporation

Processes - They have it all figured out. From releasing code to upgrading your laptop to the newest version. Most of the problems have people dedicated to them you just do what you do best. On the other hand, sometimes your fresh idea needs to go through five layers of management to be eventually rejected god knows why which can be frustrating
Scale - If you get lucky enough and work with one of the flagship products of big corp you will encounter another layer of problems connected with scale. Designing or even creating system architecture at scale is one of the most interesting and horizon-expanding things software engineers can work on
Mature product - As a junior developer, this is an advantage. The codebase is battle-tested in production and (hopefully) written in a solid way. You can learn only by reading code seniors have written. As usual, this comes with a disadvantage. There are chances that the majority of problems are already solved and as time passes your work is reduced only to copy-pasting new features

Software House

Changing projects - In a software house, it is very rare to work on a project for more than 18 months. Projects have milestones and after completion, you are rotated out. This brings advantages like new fresh projects so boredom is reduced drastically but on the other hand, you don't have a stable team so sometimes those special bond between coworkers is missing. Also, you miss the "beautiful" part of maintaining your own code
Always being the external guy - This is natural. If you work for a software house you are essentially a contractor. I've seen exceptions but usually, you are treated slightly differently. I've seen projects which had two different sets of meetings with different depths of information provided - external & internal. Also if the company is struggling financially contractors are first to go
Tight deadlines - Although architects and senior developers are part of the initial contract agreement with the new client and they discuss project estimates in the end its sales department which puts the deal on the paper. The tighter the schedule the more money is to be made for your company. This often results in milestones that are tighter than it is healthy

Startup

Wearing many hats - In the beginning you get hired as an Angular frontend dev but in three months you are forced to write a new GoLang service and integrate it into the NoSQL database. You have registered a database account under your company email so now you are owner, maintainer, and overall go-to person for that service and DB. I liked it but some people feel overwhelmed.
No Processes - Exact opposite situation as in big corp. If you are used to them it can be challenging and frustrating. On the other hand, if you like to operate under the radar of e.g HR department this is the place to be :)
Not enough data - If you have zero or few customers it's a lot harder to make informed decisions. Most of the time you are guessing what might or might not work. It's fun and exciting unless you are the person who gets mentally attached to your code. You just can't. A big portion of the code is written to be thrown away get used to it it's natural.

There's a lot more to write about different types of companies. If you want me to put together a detailed post about differences I have encountered between them leave a comment 🙂

Product types

Internal tool / library
Publicly facing application
Back office system

Different product means different business requirements.

I have worked on an internal library used by more than half of a dozen teams across the company. Gathering requirements, Communicating changes, designing APIs, making the codebase friendly to outside contributors was my daily bread.

On the other hand, working on publicly facing e-commerce solutions thought me the importance of SEO, performance, and super fancy pixel-perfect UI. You would never spend 3 months optimizing TTFB on the internal tool mostly because nobody gives a damn about it

There is no right or wrong in terms of product types. Just try as many as you can so you know what is the best fit for you

Domains

You are as many times ~~human~~ engineer, as many ~~languages~~ domains you know.

I have worked on projects in a hell of a lot of domains.

Software security, Fashion, Logistics, Finance, Government services. Real estate, Marketplace, Credit cards ...

Each of them was unique and had different challenges. At some point in your career, things eventually start to get repetitive no matter how much you are getting out of your comfort zone (new languages frameworks, etc ...). The less you are willing to experiment the sooner it happens. At that point, domains start to be the interesting thing. If you are not just coding shovel™ and getting involved in product ideas then the domain itself starts to be the fun part. Besides that, you can learn a lot from interacting with people from different domains

Conclusion

Throughout my career, I've experienced all of the above and I am thankful for that.

It was partly luck partly my own initiative. I do not encourage job-hopping in any way. Leave your job when it makes sense and know when it doesn't. E.g I stayed at one company a lot longer than I should but I enjoyed the benefits of having a great mentor. All in all, if you decide to leave try something new. It will help you immensely.

🌄 Let your junior team mates rise

Zikitel22 — Wed, 05 Jan 2022 18:19:31 +0000

So you got that team lead promotion. Congratulations!. Chances are that the team you are about to take responsibility for has few junior developers and you are wondering how to handle it.

Or maybe, a new junior developer is about to join your team. It's been a while since that last happened so you want to refresh how to make sure fresh acquisition has a smooth start. Take this article as an opinionated step-by-step guide for turning fresh out of Bootcamp/Uni newcomers into valuable team members you can rely on.
During my career, I have mentored dozens of juniors. Each of them was unique and I had to make adjustments here and there, but generally, the following points worked for most of them.

Write documentation

Over the days and months, your product grows, and naturally, the codebase follows. People who wrote the code will come and go and so will the knowledge.
It's not in human power to keep all the information about business logic, architecture, infrastructure, and processes in your head. It's not the most fun task but find time to do it.
It is obviously a no-brainer and ideally needs to be set up beforehand. But in case you haven't done this yet no worries. Sit with newcomer go through module or service, explain high-level view. Then leave figuring out details to them and as a final step let them write docs. Win-win situation.

Overcommunicate & undercommunicate (sometimes)

So new guy went through the initial onboarding process and is ready for the first task. You click that assign button on what you think is a trivial task that would take you half an hour.
You are a reasonable guy so you expect results at the end of the day or tomorrow at worst. But well that was Monday now it's Thursday afternoon and no PR was submitted.

The problem with the juniors is that they tend to be afraid to ask any questions, especially what would they perceive as stupid ones. Or on the other hand, would spam you with stuff they should be able to figure out by themself.

The first group would be stuck for hours with some random compilation error due to missing access rights or because they forgot to pull a new docker image from the nightly release.
The ideal situation is to have them sitting next to you if you are working onsite to keep an eye on them
As we're living in covid-19 time it's a good idea to ping a new team member once in a while in a chat with friendly hows the task going or is there anything I can help you with? questions. Daily team meetings aren't enough for this. Do it in one or one fashion.

Members of the latter group on the other are very eager in asking questions but if you don't respond immediately they tend to figure it by themselves (if they are any good) and that speeds up their learning process.

It shouldn't be that hard to figure out to which group your new colleague belongs and act accordingly. Most will fall somewhere in between so you want to use a mixture of these approaches

Do code reviews

I have always felt this is somehow a standard part of the development process in every company. Except, it isn't. Among the million reasons why the team is not doing (proper) CR's are - laziness, we don't have time for this, we write golden code mentality or it's so trivial it doesn't need code review. Don't fall for this it is the road to hell.
Don't get me wrong it consumes the time of senior team members but benefits for juniors are invaluable and over time you will realize that they greatly benefit the whole team.

Now, you should be pretty hard on code reviews. It's not uncommon for the newbie to have that first PR approved on 4-5th iteration. When I'm doing code review I do actually make difference between senior's and junior's PR. For seniors, I usually leave brief comments ie "Does this impact performance in any way ?". For juniors, though I tend to leave lengthy comments with links to resources I think could help them understand what I'm concerned about.

From my experience, almost 100% of juniors are happy and have a real sense of accomplishment after their first pull request was approved. Afterward, I asked all of them the very same question. "Hey Susan how does your first draft of code compares to what we are actually merging into master". The answer is always "I love it".

I'm not saying it because it sounds good for the article but because it's true. It requires your time, a lot of time, in the beginning, to be honest. But in the long run, it will pay off I promise.

Don't let them get comfortable

I have a little story here. At some point, I joined the project as a senior front-end engineer. Everything went well I was shipping features, improving performance, had sleepless nights due to random memory leak, etc. Nothing too unusual you could say.

One day team realized we are hella short on backend developers. In addition, the HR department wasn't doing its best in terms of hiring. So as I already had experience with the backend for some years, I volunteered to help. Sounds good, yeaaaaah no.

My experience was Java 6 monolithic project compiling for 2 hours. Instead, this was Scala microservices exposing GraphQL API, using things like Kafka or gazillion of AWS services. Needless to say, I was clueless.

I can tell you time travel is real. In a blink of an eye, I went back 8 years back to my junior days. People in general, especially programmers tend to quickly forget how hard is to learn anything once we master it. After some years you know how the network layer works, what are red flags in particular functions, how a web page is rendered inside out, and a lot more. What is blurred is how we have gained that knowledge. Experience, series of AHA moments, and good mentors. Junior devs at the beginning of their careers haven't gone through it. Keep that in mind at every point.

It was hard at first but in 3 weeks with the great help of my mentor, I shipped my first production feature in service A. Oh boy, what a sense of accomplishment I had. Instant endorphins, senior ninja rockstar backend dev at your service high-fiving all his friends. Yeeaaaah no ... again.

I was instantly assigned a new task in service B unrelated to service A. Sigh, back to square one. After that story repeated itself with service C.

This went on for the next at least half of the year. I'm not gonna lie, it was hard, but eventually, I was able to understand and discuss most of the complicated features implemented across multiple services. If, in the beginning, I had settled with my knowledge of service A all of that wouldn't happen.

I have been using this technique since with awesome results. You can apply this on the backend as well as frontend. Just don't let them settle

Ownership

In my mind, this is the last step of "onboarding". Naaaah not that HR checklist onboarding stuff. Think like graduation for a junior developer.

It usually comes 6 to 12 months after joining the team. Junior developer now understands how things work under the hood of your project. Does not make the same mistakes seniors already pointed out in code reviews, ask correct questions, and/or comes with his own ideas on how to improve the codebase.

Select next relatively big isolated task. It can be anything. Implementing new product feature, improving accessibility of mobile app, rewriting legacy module, migrate from MongoDB to DynamoDB. Anything!.
If a task involves architectural decisions, of course, keep eye on the process and help, you don't want to get the product into trouble.

From my experience implementation, itself tends to be the easiest part. Once it passes QA and it's live for some time all bugs and improvements should be handled by the junior. That way they will learn from their own mistakes (again) and see what wasn't thought through.

Conclusion

If you went through all the steps kudos to you. You now no longer have a junior developer but you have a real teammate and maybe friend capable of doing almost any task product requires. It took a lot of time but think of it as an investment that will pay off. Your work is done. Well except that a new junior is joining next week ...

Discuss

Let me know what are your best tips, to introduce junior devs to your team? Or what would you like to be your introduction?

Platform similar to dev.to primary for backend devs

Zikitel22 — Mon, 12 Oct 2020 12:59:21 +0000

I like dev.to don't get me wrong, but it is little frontend heavy for my current needs
see
https://dev.to/t/backend - 351 posts
https://dev.to/t/frontend - 1418 posts

Can you recommend similar platforms but more targeted to backend? Mainly architecture, infra, DBs regardless of language

VS Code + React + Typescript code quality setup 2020

Zikitel22 — Sun, 03 May 2020 00:00:00 +0000

So here's the thing.
I started several projects combining React and Typescript lately and found myself repeating same setup over and over again.
Usually on project's first day i would do only this chore and esentially waste one day.

Dont get me wrong create-react-app offers nice start but gives you almost nothing in terms of code quality.

As my teams usually consist of non trivial percentage of junior developers i want to make sure common mistakes are caught early, code is formatted well and commit messages make sense.

If you are experiencing same problems keep reading
We will be using yarn as our package manager throughout this post.
If you dont have it installed yet do it via npm install -g yarn in your terminal

1. Lets start with creating our project

npx create-react-app dev-experience-boilerplate --template typescript

We are using npx which is npm package runner and executes create-react-app package without installing it globally

Above code is equivalent to

npm install -g create-react-app
create-react-app dev-experience-boilerplate --template typescript

3. Linting (Eslint)

Linting is by definition tool that analyzes source code to flag programming errors, bugs, stylistic errors, and suspicious constructs. We will be using eslint - linting tool for javascript.

First lets integrate eslint in our IDE by installing VS Code extension from marketplace

In Next step will be installling all needed dependencies

yarn add eslint eslint-config-airbnb eslint-plugin-import eslint-plugin-jsx-a11y eslint-plugin-react eslint-plugin-react-hooks
@typescript-eslint/parser @typescript-eslint/eslint-plugin eslint-plugin-header eslint-plugin-import eslint-config-prettier --dev

That is lot of dependencies.
What we did here? Well we installed bunch of plugins
Lets look at them one by one

eslint - Tool itself
eslint-config-airbnb - Good guys in airbnb made their eslint configuration public. Everyone can use extend and override defined rules
eslint-plugin-react - React specific linting rules for ESLint
eslint-plugin-jsx-a11y - Set of accessibility rules on JSX elements. We want to be proper developers and deliver best possible experience also for impaired visitors of our application. One of such rules can be that <img> tags should have alt attribute so screen reader knows what is on image. If you forget to add alt wslint will yell at you
eslint-plugin-react-hooks - Since react version 16.8.0 we are writing majority of our components in hooks. We want them write right.
@typescript-eslint/parser - Sice our project uses typescript we need to tell eslint that our code is not vanilla javascript and needs to be parsed
@typescript-eslint/eslint-plugin - Set of rules for typescript
eslint-config-prettier - Eslint plugin that removes all rules that can possibly conflict with prettier which we will install in next step
eslint-plugin-header - EsLint plugin to ensure that files begin with given comment. I personally like when every file starts with header with basic info like Author and Date. When you work in larger team its a nice way to see ownership of file and when something is not clear or right you know who you should bother with questions
eslint-plugin-import - Linting of ES6 import/export syntax

Now when everything is installed lets define our rules

This is very opinionated but heres what works for me.

In root of your project create file named .eslintrc and paste following code snippet inside

{
  "parser": "@typescript-eslint/parser",
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/eslint-recommended",
    "plugin:@typescript-eslint/recommended",
    "react-app",
    "prettier",
    "prettier/@typescript-eslint"
  ],
  "plugins": ["@typescript-eslint", "react-hooks", "header"],
  "settings": {
    "react": {
      "version": "detect"
    }
  },
  "rules": {
    "header/header": [2, "block", [{ "pattern": " \\* Author : .*" }]],
    "@typescript-eslint/consistent-type-definitions": ["warn", "type"],
    "@typescript-eslint/explicit-function-return-type": "off",
    "@typescript-eslint/explicit-member-accessibility": "off",
    "@typescript-eslint/no-angle-bracket-type-assertion": "off",
    "@typescript-eslint/no-non-null-assertion": "off",
    "@typescript-eslint/no-unused-vars": [
      "error",
      {
        "argsIgnorePattern": "^_",
        "ignoreRestSiblings": true
      }
    ],
    "@typescript-eslint/no-use-before-define": [
      "warn",
      {
        "functions": false,
        "classes": false,
        "variables": true
      }
    ],
    "import/no-extraneous-dependencies": "warn",
    "import/order": [
      "warn",
      {
        "newlines-between": "always"
      }
    ],
    "no-case-declarations": "warn",
    "no-console": "warn",
    "no-debugger": "warn",
    "no-else-return": "warn",
    "no-param-reassign": "warn",
    "no-undef": "off",
    "no-unused-vars": "off",
    "no-var": "warn",
    "object-shorthand": "warn",
    "padding-line-between-statements": [
      "warn",
      {
        "blankLine": "always",
        "prev": "*",
        "next": "class"
      },
      {
        "blankLine": "always",
        "prev": "*",
        "next": "for"
      },
      {
        "blankLine": "always",
        "prev": "*",
        "next": "function"
      },
      {
        "blankLine": "always",
        "prev": "*",
        "next": "if"
      },
      {
        "blankLine": "always",
        "prev": "*",
        "next": "return"
      },
      {
        "blankLine": "always",
        "prev": "*",
        "next": "switch"
      },
      {
        "blankLine": "always",
        "prev": "*",
        "next": "try"
      },
      {
        "blankLine": "always",
        "prev": "*",
        "next": "while"
      },
      {
        "blankLine": "always",
        "prev": "block-like",
        "next": ["let", "const"]
      }
    ],
    "prefer-const": "warn",
    "react/jsx-boolean-value": "warn",
    "react/jsx-curly-brace-presence": "warn",
    "react/jsx-key": "warn",
    "react/jsx-sort-props": [
      "warn",
      {
        "callbacksLast": true,
        "reservedFirst": true,
        "shorthandLast": true
      }
    ],
    "react/no-array-index-key": "warn",
    "react/prefer-stateless-function": "warn",
    "react/self-closing-comp": "warn",
    "react-hooks/rules-of-hooks": "error",
    "react-hooks/exhaustive-deps": "off",
    "yoda": "warn"
  }
}

I dont want to go into much details here but i encourage you to sit with your team go through all of them, and discuss what works and what doesn't for you. There is no single right answer to how .eslintrc should look like

Last thing we need to do is to set up linting command in package.json

Into section scripts add following snippet

 "lint": "eslint \"src/**/*.{ts,tsx}\"",
 "lint:fix": "eslint --fix \"src/**/*.{ts,tsx}\""

Now when you run yarn lint in project root
You should see output similar to this

Ok so we have 14 warnings. Lets try to fix them by running yarn lint:fix in project root

Awesome down to 6 with no effort. Eslint sorted props added blank lines for better readability and more for us for free.

There are some console.log statements in serviceWorker.ts
For some reason i want to leave service worker as is and not to lint this partiular file.
Eslint comes with solution for that.

Lets create .eslintignore file in project root and add following content inside

src/serviceWorker.ts

Now after running yarn lint there should be no errors. Life is beautiful again 🦄

2. Prettier

Prettier is code formatter that supports number of languages and can be easily integrated into VS Code.

Similar to eslint we first need to install VS code extension

Add dependencies

yarn add prettier --dev

And create configuration file

Lets create file .prettierrc in project root and paste following content inside

{
  "singleQuote": true,
  "trailingComma": "all",
  "printWidth": 100
}

Thats everything for prettier now your code will look nice and consistent across all files

If for some reason you dont want to prettify some of your files you can create .prettierignore file in your project root

3. Precommit hook

Now. You can run eslint and prettify every time you are about to commit your changes but lets be honest . We all forget.
You cannot forgot if husky barks at you though.
Husky is handy tool that prevents you from accidentaly pushing changes that are well.... not ideal into repository.

Lets see it in action.

First install dependencies

yarn add husky lint-staged --dev

Add following into your package.json's script section

"precommit": "lint-staged"

And following to the end of package.json

"husky": {
    "hooks": {
        "pre-commit": "lint-staged"
    }
},
"lint-staged": {
    "src/**/*.{js,ts,tsx}": [
      "prettier --config .prettierrc --write",
      "eslint --fix \"src/**/*.{ts,tsx}\"",
      "eslint \"src/**/*.{ts,tsx}\"",
      "git add"
    ]
  }

To see if our setup works lets create unused variable in App.tsx. And try to commit our changes via git add . and git commit -m "This shouldnt work"

And indeed husky barked and we have to fix our code in order to be able to push it into repository.

4. Commit message hook

Last thing i want to cover is consistent naming of commit messages. This is common mistake in lots of repositories. You can of course create your own git hook but i recently fell in love with git-cz which is tool for interactively commiting changes via your favourite terminal.

Installation

yarn add git-cz @commitlint/cli @commitlint/config-conventional --dev

Add following into your package.json's script section

 "commit": "clear && git-cz"

Add following to the end of package.json

 "commitlint": {
    "extends": [
      "@commitlint/config-conventional"
    ]
  }

And last thing is to tell husky to run our new commit-msg hook
We do this by changing husky section in package.json

"husky": {
    "hooks": {
      "commit-msg": "commitlint -E HUSKY_GIT_PARAMS",
      "pre-commit": "lint-staged"
    }
  },

We can test our new git hook by running yarn commit

You can see this awesome cli tool that lets you choose type of change you are about to commit and more. This can be all configured
In default config you will fill in folllwing:

Type of change (test, feature, fix, chore, docs, refactor, style, ci/cd and performance)
Commit message
Longer description (optional)
List of breaking changes (optional)
Referenced issue (i.e JIRA task number)

And commit messages are now consistent across whole team
Plus you get neat commit message icons like this

You can find whole working solution on github
If you liked this article you can follow me on twitter