With over ten years of experience in engineering, I've found that delegation can be tough for those who always feel the need to stay in control or feel guilty about assigning tasks. However, mastering delegation is crucial for building strong teams and growing as a leader.

Why Delegation Matters

Delegation is more than just lightening your workload. It's a way to empower your team, boost efficiency, and establish trust.

Proper delegation also helps your team members grow and learn. By assigning tasks that develop their skills, you are preparing them for future leadership roles. When your team feels empowered, they're likely to be more creative and carried out tasks independently.

Effective delegation makes people feel respected, trusted, and motivated to succeed.

Problems in Delegating Tasks

Managers often struggle with either delegating too little or too much.

Under-delegation - Some leaders don't delegate enough because they fear losing control, a mindset which leads to excessive workload for the leader and stunts team growth. It's important to delegate tasks that matter and contribute to team member growth, rather than just simple jobs.

Over-delegation: Conversely, over-delegating can overwhelm your team, causing stress and dampening morale. This occurs when leaders assume their team can manage everything without enough guidance. It's crucial to keep a close eye on the team's capacity and aptly match tasks to their skills. Clear instructions and ongoing support can help minimize stress.

There is a great explanation about this topic in “The Manager’s Path” book by Camille Fournier.

Tips for Delegating Well

Know What to Delegate

Not every task should be moved off your plate!
Consider delegating tasks that will challenge your team and promote growth, rather than only the easy ones (yes you should delegate the easy ones). Evaluate your workload to identify opportunities for growth for your team.

Match Tasks with Employee Talents

Each team member brings unique skills to the table. Understand their aspirations and assign tasks that align with their career goals and strengths.

Set Clear Goals

Be explicit about expectations and objectives. Allow your team the freedom to determine how best to meet these expectations, which will foster both creativity and accountability.

Provide Needed Resources

Ensure that your team has the necessary tools, sufficient time, and any required training to complete their tasks effectively. Sometimes, this includes connecting them with knowledgeable contacts.

Encourage Communication and Feedback

Cultivate an atmosphere where feedback is valued. Regular check-ins keep everyone aligned and fortify the bond between you and your team. Remember, feedback goes in both directions.

It’s important that you as a leader unlock your team's full potential and achieve desired outcomes. Effective leadership is about nurturing your team and creating an environment where everyone can perform at their best. Delegation is the tool one cannot avoid and the sooner you master it, the better leader you’ll become.

It’s up to you to recognize those team members with great potential and push them forward.

Subscribe now

Back in the days, we used SVN as a Version Control System (VCS). The most popular client TortoiseSVN was a window into how to push and pull your code to the trunk. Wait what?

Yes, some version of Trunk Based Development was a thing a long time ago, we just didn’t give it a name. Then Git became popular as a more powerful solution, and soon enough, GitFlow established itself as a dominant branching model to organize a codebase on VCS.

Before we move on, let me tell you - this is not just another post about trunk-based development.

Trunk Based Development

All the cool kids from the block are using it today. The main idea is to use one long-lived branch and everyone contributes directly, or by merging short-lived branches into it.

Nowadays, Trunk Based Development is enabled on Git by imposing the master/main branch as the only long-lived branch. CI/CD pipeline is set on this branch to deploy the changes to production.

Advocates of this approach will often say that this is the only way that enables true Continuous Deployment and Build-Once-Deploy-More strategy.

It’s true. The advantage of this approach is that you can push to the trunk a couple of times a day, and deploy to production at the same rate. Although unintuitive, it reduces the amount of serious defects in the product.

As a side effect, there is less operational overhead, and fewer communication lines, and eventually, the team working on the product can shrink and be simpler. That’s because in order to deploy frequently, user stories are often very small. QA process as we think of it is minimal or not existing, as developers are doing QA mostly.
As a cherry on top, the just apply different environment variables to the already-built container and deploy it to a different environment. Magic.

GitFlow (and its variations)

As a branching model, it assumes more than one long-lived branch and a couple of different types of short-lived branches.

Feature development

Main Branch (main):

• main is a production-ready branch. The code here is stable and usually represents the version of the code that is currently live in the production.

• Deployments to production are made from this branch.

Development Branch (dev):

• This is the primary development branch where all the features, bug fixes, or any other code changes are merged.

• It's ahead of the main branch in terms of new code changes.

Feature Branch (feature/user-registration as an example):

• Branches created for developing specific features.

• These branches are short-lived and exist for the duration of specific feature development.

• They are branched off from dev and will eventually be merged back into dev once the feature is complete.

Release Procedure with GitFlow

Release Branch (release/0.9.0)

When you are ready for a release, a release branch is created off the dev branch. This branch is used to prepare for a new production release. Any final adjustments (like bug fixes, and documentation) needed for the release are made here.

No new features are added to this branch.

Deployment

The release branch undergoes deployments to different environments for testing.

• First, it's deployed to a Staging Environment.

• Then, it's deployed to a Demo Environment.

• Once everything is tested and ready, the release branch is merged into the main and is deployed to Production.

It's also a good practice to merge the release branch back into dev to ensure any last-minute fixes are incorporated into the development branch.

Build-Once-Deploy-More with GitFlow?

A general misunderstanding with GitFlow is that every branch needs to have a build pipeline. This is especially true with the master/main branch.

Nothing is stopping us from using artifacts built from the release branch treating is as immutable artifacts, and promoting them across different environments.

Which one is better?

Neither and both. Set the process based on the needs of your current context. Here is a quick rule of thumb.

When to use GitFlow?

• When you have a junior team.

• When your release cycle is measured in weeks and not hours.

• When you start a greenfield project.

• The expected scope is a couple of months only.

• If your team doesn’t have established a developer culture that promotes stability-before-delivery-speed.

When to use Trunk Based Development?

• When you deploy multiple times a day.

• Your team is composed of experienced engineers.

• There is a high trust culture in the team. If you as a dev, break something simple in the production by pushing an untested codebase, you’ll break the development culture of such a team, and you’ll feel pretty bad about it. What’s more, you’ll undermine the trust given to you.

• Long-running project, which already found product market fit and is stable to some extent.

• When the advantages of this approach are greater than the risks of breaking something in the process.

Reality Check

How many of you are working in such a team? Lasts for years, working on a continuous product? Although I admit I am biased toward the software service industry, most people I know are changing projects on a yearly basis, or often.

Software developers with the luxury of working in the same team, with established trust, culture, and norms, and the same product are usually in big tech.

I am not rooting against any approach, but I am rooting for you not to follow the hype by default. Take wider context into consideration, look around you calculate the risks, and then make a decision.

Why is this? Well, here is most simple answer.

Nobody likes to see coworkers and peers that are sitting silently and waiting for work to come to them.

What’s more, if there is no work assigned you won’t hear of them at all.

While one could argue that it is our job to do what we are assigned to, no one forbids us asking for more work when there is none.

And usual responses are in line of “I know, but I just feel I’m not motivated enough” or “This project is the worst I have been working on”, “My previous team was much better than this one” and so on.. “I’m not paid to do that.. “ (really?)
Justifications.

Proactivity is a state of mind

And it can take many forms.

You don’t have a task?
Ask for one! Still no task, make one for yourself. At least in software engineering, there are always things you can adjust on your project. Refactorings to be made. Tests to be written. Tech debt to be reduced.

Your coworker is struggling?
Offer your assistance. Help them and teach them. It’ll feel great!

You are a junior and lack experience?
Do the POC, ask your senior colleagues or managers for an advice. I personally don’t mind staying up very late to assist younger colleague that is hungry for knowledge and most people I know are the same.

You’ve noticed organisational inefficiencies?
Do something about it. Come up with a proposal to your manager, it might become a solution and help hundreds of people.

Thing is, we can always get silent, sit and wait. But:

• It’s a state of mind which doesn’t spark curiosity.
  For a software engineer, it is very dangerous.

• It’s a state of mind where you’re not making an opportunity for yourself and depend on others.
  You can produce perfect code, but, it will drive you to half of the journey.
  Combine those skills with readiness to contribute to your organisation further and the magic will unfold.

• It’s a state of mind that spirals down and makes you miserable because you see that others around you are succeeding, like they have a secret formula or something.
  No, they just speak up and get noticed, included and promoted.

Motivation

I have a simple rule. When working, I am giving 100+%. There is work to be done, and someone has to do it. There is no one available - then it’ll be me. And I don’t have to like it, but still, it has to be done.

Anything less then that, and I am working against myself, because I am not fully contributing to organisation that I belong to.
What’s worse, I am working against my very colleagues, and their families.

Yes, one can lack motivation to push things through, to speak up, to contribute, but then ask yourself: Have you tried making a change? Have you led any initiatives? Are you enjoying in doing what you do, in an organisation you’re at?

Maybe you’re in a golden handcuffs, too comfortable with the salary and benefits, or you’re thinking about your family and the risks involved? These are all valid reasons, no shame in that, but especially then it makes no sense to sit and wait.

There are many ways to find motivation and usually, motivation cannot be served, nor is anyone obliged to make one for you.

Act now.

Being a manager is not an extension of a previous role.

It can be easy to fall into the trap of believing that your position as a team manager is simply an extension of your previous technical role, where relationships with team members may have been more equal.

However, the truth is that as a manager, you have the power to make decisions that affect your team members' careers.

This transition from a technical role to management can create a strain on relationships with team members, particularly if you are not fully aware of the power dynamics at play.

It's not uncommon for new managers to be taken aback when team members begin to keep things from them, as they become less informed than they were previously. To overcome these challenges and improve communication and collaboration with your team, it's important to recognize and address the power dynamics at play. Consider the following strategies:

1. Avoid monopolizing team discussions. By refraining from being the first to contribute, you can create an environment that values diverse perspectives and leverages the collective wisdom of your team.

   Leaders eat last, therefore let your team members speak first.

2. Actively invite input from your team members. Some team members may feel hesitant to contribute to discussion. Maybe that’s because they expect their manager to drive the conversation, or think they don’t have anything valuable to add.

   You can create a more inclusive environment by inviting your team members to speak up. It’s simple.

3. Be intentional in your actions and comments. As a manager, your words and actions can set the tone for the team. Take care to be thoughtful in your approach to avoid unintended consequences that may negatively impact team morale.

   Remember that video when the teacher takes a deep breath before they enter the classroom. That.

4. Build trust with each team member. While the inherent power imbalance cannot be completely removed, building trust can create a more transparent and approachable environment.

   While building trust is obvious, it has to be stated all over again. It’s importance must not be neglected.

5. Empower team members by delegating decision-making responsibilities. By doing so, you can mitigate power imbalances and foster a culture of collaboration that grows the skill sets of your team members.

Effective team management is a continuous process that requires ongoing effort and attention. While the strategies outlined above can help address the power dynamics at play, there are countless other approaches that can be taken. Experienced managers understand this reality and are constantly adapting their approaches to suit the needs of their team.

For those new to management, the challenge lies in accepting and adapting to the dynamics of their new role. It may be difficult, but it is essential to prepare for the reality of making decisions based on the power of your position.

On January 1st, 2023 I decided to deploy a working web app in two weeks. Two weeks later, Stash to Read was live and functional. It’s a proof of concept, but works.

How did I do it? I built this web app with the no-code tool - bubble.io

Bubble is one of the most popular no-code solutions for building web applications (source: reddit).

Why should we use no-code solutions?

Proof-of-Concept and Minimum-Viable-Product type applications are a great fit for no-code solutions.

You have an idea and a very limited budget. Therefore you wanna push your product to market as fast as possible. You want to validate it and try to find a product-market fit. If so, then seriously consider a no-code tool like Bubble.

With it, you’ll be able to build a product in an extremely short period, with the minimal team required.

No-code by its definition means absolute technical debt.

You have to have this in mind, as the tool has its own limitations that might be hard to overcome. Once your product gains traction, your user base grows and you get the funds from investors, you’ll most probably have to rewrite everything from scratch.

Bubble core concepts

Bubble is relying on three major sections to help you define the look-alike and the logic of your app:

• design

• workflow

• data

This is exactly how they sorted options in their working environment.

Design

This is where we create a UI. A palette of fully functional elements is already at our disposal. Buttons, inputs, dropdowns ..everything.

All elements are organized into groups. A group can have an orientation, either as a column or a row. By stacking groups, we define the layout of the page.

80% of our time is spent inside the "Design" section. More specifically in the property editor of specific elements on the screen.

Property editor

With the property editor, we define the element style, element behavior in layout, and various conditionals.

Style - By adjusting the style, we affect how the element looks like.

Layout - By tackling layout properties, we define how the element should stack in its parent group.

Conditions - By setting up the conditionals for an element, we are able to affect element behavior when a certain state is changed (like page width for example).

Using a property editor was usually straightforward for me. There are some specific use cases that I found hard to overcome (more about these in the next posts).

Subscribe now

Every element on the screen can be hooked up with the workflow and the data to connect it to the business logic.

Workflow

With workflow, we define a series of actions that needs to happen once a certain event is triggered.

The most powerful aspect of the workflows is the actions that you can chain one after another. While these actions can be as simple as "Reset input", they can be as complex as "Sign in with Google" or "Charge current user".

In the screenshot below, you can see multiple triggers defined. Trigger for the “Submit button” click as expanded. It shows the chain of actions necessary to complete when the user clicks a Submit button.

New actions can be added from the dropdown menu and are organized into logical groups, as shown below.

Data

This is the area where you'll spend less time, but it is the core of the whole app - the database.

In Bubble, the database is abstracted a bit.

• We have the possibility to create a data type (table), with fields (columns).

• It is possible to create joint tables, but you don't really define the foreign keys and similar stuff.

• We have no control over indexes and query optimizations at all.

• Data privacy is granular and is set for every data type and field.

• You can import and export your database.

• You have really no control over schema migration from one version to another.

How do elements, workflows, and data work together?

• Groups can set the data type they work with. What does this mean?
  Let’s say that a group contains text fields for displaying the user’s first name and last name. In this case, the data type assigned to a group will be 'User', and child elements can reference a parent data type and access its properties.

• The element usually loads specific data of its parent. If the group data type is 'User', then on the 'username' text element we would say 'Parent's User's username'

• Workflow is linked to one or more events that an element emits.

  For example, if a user clicks a button, a click event will be emitted and the workflow will be triggered.

• Workflow has access to elements and can read their values, and create or modify records in the database.

FAQ

Does Bubble support the development environment?

Yes, it does. By default, you can differentiate application versions and data between the development and live environment. In fact, on more expensive packages, you can create multiple environments.

How to manage user sessions?

You don’t, it is done by Bubble. You can always access “Current user” and inspect whether the user is logged in or not, to access its data, log the user out, etc.

Is it possible to query the data directly?

Let’s put it like this. You cannot query data in an SQL fashion. There are specific and quite limited options to load data into existing elements. There is a possibility to open the database through API. Still, complex SQL queries are not possible by default.
It suffices to say that you can install SQL plugins and run SQL queries against external databases.

How to control data privacy?

Bubble base privacy on data type level (database table), where you can specify multiple sets of rules with access rights for every field(column) in data type.

Who owns the code?

That’s not important. You own the intellectual rights and the Bubble cannot copy-paste your app as its own.

What’s the quality of generated code?

Who cares, it works.

Is it possible to create a top-level style and color scheme?

Absolutely.

How to reuse elements between pages?

You can create reusable elements and add them to multiple pages. The header is one example of the most common reusable element. Sign-up popup might be a good candidate as well.

How to connect to an external API?

Via plugin. There is a vast amount of plugins available and one of them is the External API plugin. With it, you can connect to API and consume its content.

Where is the app hosted?

On Bubble servers. Depending on the package you purchased, you have specific guarantees over availability.

Is Bubble GDPR compliant?

Yes.

What if need to load millions of records from the database?

You won’t. If you have this use case, think of whether Bubble is the right choice for your product. Bubble time-outs queries after 3 seconds.

Do you have some unanswered questions? Leave a comment below.

Leave a comment

Small disclaimer:

I am using Bubble for less than a month and my experience is limited. I wanna learn as well and improve my skills over time. It might be that what I wrote above is absolute nonsense. If so, please let me know, I’ll be grateful to learn from you!

This is a Part #2 post on card processing fees. I will explain in details how Stripe fees work and what to pay attention to when setting up Stripe account, so that you avoid unwanted costs.

Part #1 is about generic explanation of how card processing fees work. In case you missed it you can read it through here.

Crispy Engineering

Credit Card Processing Fees: What You Need to Know

As of January 31st Gumroad made an announcement that they will increase their margin to 10%. In the email they sent, there is one tiny detail (highlighted below). They presented it in a way that creators should be happy because of transparency, but in reality, they are saying…

Read more

3 years ago · Dusko Bajic

To unwrap Stripe fees, let’s start with two most basic factors:

• Business location

• Customer location

Business location

Stripe has a similar, but different fee structure depending on the country in which you registered your account.

The most important factor, defined by business location is the choice of settlement currency.

Settlement currency

Settlement currency is the currency of your bank account. Usually, this is the official currency of your country.

In some countries, you can set a default settlement currency to be USD, even if the official currency is some other (like EUR, or GBP). This is important because you will avoid currency conversions. With Stripe, you can set multiple bank accounts and have transactions automatically routed to a bank account with matching currency.

Depending on the type of business you’re running, you can make early optimization if you know where your future customers are coming from. This is a bit difficult for digital products, as your market is the whole world. Therefore, some other rules apply as well, as customer location plays a huge role.

Customer location

On the opposite side of the transaction flow, there is a customer with similar factors. What affects the card processing fee are the following:

• country of residence

  Location of the bank that issued your card.

• credit card currency

  This is the currency of your bank account, usually, the official currency of the customer’s country/region.

The parameters above are affecting whether additional fees will apply to the transaction flow. Those additional fees are:

• cross-border fees (often called international payments)

• currency conversion fees

Cross-Border Fees (international payments)

Whenever someone uses a card issued in a country/region other than the country/region of a POS, a cross-border fee will apply. There is no difference in whether the card is present or not.

With Stripe, this is where it comes to play when you choose the country to register your Stripe account. Registering in the USA means that every payment with a card issued outside of the USA will have a cross-border fee added on top of the domestic fee.

In the table below, we can see payment processing fees with a cross-border fee included.

For someone running an online business, this table is more relevant than the previous one. If you’re globally present, selling digital products, chances are you will have many international buyers.

Currency conversion

With currency conversion in place, things get very shady.

For businesses, currency conversion happens when the card is charged in a different currency than the settlement currency.

Fortunately, businesses can affect this by choosing the charge currency for transactions. This is also called a presentment currency, as the product price will be presented to the customer with that currency.

Almost always, businesses match presentment currency with settlement currency, in order to avoid additional transaction costs. This also means that the costs of currency conversion are transferred to the customer, as the customer bank will do the currency conversion from local currency to presentment currency.

A negative side effect of this is that customers will see one price on the product, and they will be charged more, due to the local bank FX rate. This leads to unclear costs to customers.

In some businesses (especially in service B2C), customers will complain about unclear costs. This is where the business can offer customers the choice of the currency they wanna be presented/charged with (the customer decides about the presentment currency).

This means that the transaction could be more expensive for the business, but on the other hand, the business could generate more sales due to the best user experience.

This results in the most expensive version of transactions for a business.

If you’re starting the business, a piece of advice is to always match presentment currency with settlement currency.

Your customers will see the price in foreign currency and they will expect some currency conversion on their side.

Othewise, transaction costs become too expensive.

UX dark pattern in presenting the product price

What businesses should never do, is “localize” the prices to customer currency, and charge in another currency.

Gumroad is letting this “UX dark pattern” happen.

On Gumroad you can present the price of your product in EUR, but the customer will be charged in USD every time. They do the currency conversion for UI purposes only. It’s safe to say that the FX rate that Gumroad used is different from the FX rate of your bank.

This means that the price that customer sees and the charge amount on their card will be different due to currency conversions applied by their bank.

Be extra careful, if you intend to make a conversion from one currency to another, just for the localization's sake. No one likes to be charged for something they didn’t expect.

In summary

When selling your digital product, make sure to think about card processing fees early by factoring in:

• Your location (business currency)

• Customer location (customer currency)

This way you will be able to mitigate additional costs from:

• cross-border fees

• unwanted currency conversion

• and currency conversion fees.

It’s important to remember if you have a huge transactional volume, you can always negotiate better terms with Stripe. Any payment processor will rather do the discount than let you redirect your traffic to some other payment processor.

At some point, the leverage is on the business side.

They presented it in a way that creators should be happy because of transparency, but in reality, they are saying

We’re gonna take 10%.

On top of that, you will be charged credit card processing fees.

How much? - Well…

What was the actual problem here for Gumroad?

Their fee was blended, and they couldn’t really tell how much they earn, depending on the dynamics of credit card processing fees.

They don’t wanna do that anymore. Their cut is 10% and the revenue is more predictable.

What are interchange fees?

Paying with cards costs, and costs both sides, the merchant, and the customer. Yet it’s a commodity of modern life. Paying for books, digital services, and whatnot, from the comfort of your home.

Let’s take a look at the credit card processing fee structure. In its most basic form card payment fees comes in three types of fees:

1. Acquirer markup

   Charged by the bank which owns the POS. Usually, the bank where the merchant has a bank account opened.

2. Card scheme fee

   Charged by the card network such as VISA and MASTERCARD

3. Interchange fee

   Charged by the bank which issued the card. Usually, the bank where the customer has the bank account. The interchange fee is the most significant part of this fee structure.

On the infographic displayed below, there are two flows executing at different times.

• Authorization flow (displayed in blue)

• Settlement flow (displayed in dotted red)

Share

Authorization flow is happening during the purchase, and the network communicates whether the customer has enough funds. This is when the reservation of funds is made as well. Usually, funds are not transferred between the customer and the merchant at this moment.

Settlement flow executes when the merchant closes the day. This is when the batch of transactions is transferred by the acquirer to the network, and the network distributes transactions to issuers.

What affects card processing fees

It comes down to risks. The riskier transaction, the more expensive.

• What is the card type (credit is more expensive than debit, a business card is more expensive than individual)

• Card present or not (online payments are more expensive, risk of fraud is higher). For example in the EU:

  • When present, interchange fee = 0.2%

  • When not present, interchange fee = 1.15%

• Visa vs Mastercard

• Business categorization - MCC - (in some countries, charities and similar services have lower fees)

• Regionality (EU is cheaper than the rest of the world due to high regulations)

  • In the EU, Debit and Credit interchange fees are capped at 0.2% and 0.3%

  • In the US, regulated banks have a cap on Debit, while Credit is unregulated.

  • Mexico is 5 times more expensive than the EU, and Australia 4 times.

Can we really affect these factors? Truth is, not really. In the areas of the world with smaller markets, but the high presence of card networks, it’s pretty much up to card networks to decide how much they’ll take.

Basically, institutions in power are card networks. And things are way more unregulated in online payments.

Online payments

In the last couple of years, the number of investments into fintech startups is measured in tens of billions. It is a very lucrative business to have your checkout form integrated into hundreds of thousands of websites.

Everyone is fighting to capture as many online purchases as possible and route transactions through their systems to the same card networks. 

You heard about PayPal, Stripe, AliPay, Adyen, Square, etc. These are default choices when enabling online payments for your product nowadays.

What is their business model? It’s collecting fees and each of them has different fee structures. 

In my next post, I explained Stripe's fee structure and optimization strategies.
Click on the link below.

Crispy Engineering

Optimizing Stripe Fees for Your Business: Tips and Strategies

This is a Part #2 post on card processing fees. I will explain in details how Stripe fees work and what to pay attention to when setting up Stripe account, so that you avoid unwanted costs. Part #1 is about generic explanation of how card processing fees work. In case you missed it you can read it through here…

Read more

3 years ago · Dusko Bajic

Martin Fowler extended this idea with “The Practical Test Pyramid”.

The current model wasn’t fit for the industry's needs anymore and by focusing on automation, he went with the test pyramid to the next level.

Here is an excerpt from this text:

Unfortunately the concept of the test pyramid falls a little short if you take a closer look. Some argue that either the naming or some conceptual aspects of Mike Cohn's test pyramid are not ideal, and I have to agree. From a modern point of view the test pyramid seems overly simplistic and can therefore be misleading.

Still, due to its simplicity the essence of the test pyramid serves as a good rule of thumb when it comes to establishing your own test suite.

Martin Fowler

The industry evolved again, and stakes have changed when it comes to testing software products.

Product size matters

I have worked on dozens of software projects in the past 13 years. They range from projects for global conglomerates in the car industry, to small startup apps.

Money poured into startups in the last decade is hard to imagine. Startups usually have one goal in the beginning. Ship fast, go to market as soon as possible, iterate fast, repeat. This results in half-baked MVPs reaching production.

It's fair to say that in the majority of cases, these products don't have any tests at all.

Those that had tests written are not even close to the test pyramid model.

Test diamond

What I saw working in practice, that organically showed up is a test diamond model.

It consists of 4 major layers.

1. Unit tests

2. Integration tests

3. E2E tests

4. Manual tests

Unit tests

Unit tests are written for critical parts of the system. If it's an accounting app, we'll test specific accounting rules as units.

Or we might test a method that is parsing a string into a number with 6 decimals precision, rounding up.

Integration tests

The number of integration tests is the largest. We lean on its stability to guarantee the working product.

Integration tests usually start from an endpoint level (with the assumption that we're building an API-exposed service).

Some teams cover these tests through Postman as well.

Advantages are:

• we're utilizing the whole call-stack vertical which helps in code coverage

• by changing the input, we can affect a different vertical to be called.

• we're testing the most likely scenario that is going to happen in the production

• less time is spent on mocking everything and running the test in isolation

• can be run in CI in the same way as unit tests.

Disadvantages are

• it's slower to execute

• test size is bigger

• more effort is put into seeding the proper data for different scenarios

E2E tests

These are complete use cases from the user's perspective. We assume UI tests in this case. E2E tests are usually written in the scale-up phase of product development.

At this point, the company has enough money and enough users to start tinkering with the optimizations of the test process.

UI E2E tests are hard to maintain. They are very slow to execute and suffer from a high percentage of flakiness in their execution.

A huge blocker is the absence of knowledge in writing testing scenarios. These testing scenarios aren't focusing on implementation details but on user experience.

Manual tests

Not everything can be automated, and that's completely fine. There are countless cases where human needs to sit and click through the product.

Usually, this is the case with 3rd party integrations.

For example, you have to upload an invoice to 3rd party service and check through the UI dashboard of that service if the invoice is there.

Not avoidable, but should be reduced to a minimum. The fact is, in the MVP stages of product development, manual testing is absolutely dominant.

So why test diamond?

Because of efficiency in product delivery, while keeping the product stable.

By focusing on integration tests, we will cover the most used code paths. A minority of users will stumble upon the bug, fine, it's 2/10. Once that happens, we'll write a bug fix for it.

By now you must be wondering:

Well, I want to tell, you, if your test setup looks more like a diamond, that’s fine. It works for others, it works for you, and everyone’s happy.

Often we’re judged and feel guilty because we’re not following some methodology by the book. It’s fine not to. Processes evolve.

“Bug-free software product doesn't exist, and it is important for a software product not to cease to exist.”

Unknown, but honest product owner

As a VP of Engineering, I constantly have to find the common ground between different parties. Throughout this time, I learned how to position myself in conversations.

I am going to show you a couple of tricks.

Judging others is so easy

Text within this block will maintain its original spacing when published

Jack: - Have you seen that message on Slack he wrote?
Mike: - Yes, I have. I can't believe he acts like that in front of the whole team.
Jack: - He has zero understading in all the work we did so far. It has been explained to him already once.
Mike: - Yeah, we're busting our a** here! He should pay more attention! Not a team work man ...not cool at all.

We, humans, have needs and expectations. Often, these expectations are not fulfilled and we got disappointed and angry with others.

So we go into a conversation. Mike from the example above would say the following.

The problem is that YOU don’t care about our team as other team members.

Blame, insults, put-downs, labels, and criticism are all forms of judgment. We are preoccupying ourselves with WHO is arrogant, ignorant, irresponsible, good, bad, normal…

Rather than telling others what we need (and not getting btw), our attention is focused on classifying, analyzing, and determining levels of wrongness with others.

Let’s look at another example, which shows that a judgmental way of thinking is built-in into each one of us.

We focus on the faults of others and miss out. It’s tragic. Because when faced with judgment, people defend and resist the critic. What happens then is an argument. When arguing too much, the environment becomes stressful, people become resentful of each other. Efficiency drops. People quit.

You get the point. So, how do we go past this?

Look behind the curtain - Be curious and observe

Let’s set the stage for what follows below:

What will you do? Act instantly? Defend yourself? Or ignore?

This is what you should try instead - be curious about what’s going on and instead of providing any reaction, first ask yourself:

What made him act like this? Something has to happen that I am not aware of. I need to know more.

Curiosity leads to observation. By observing what’s going on, we manage to pull ourselves out and take a bird-view of the situation in a completely objective way.

It’s so powerful because we are no longer attached. We don’t feel attacked, or criticized. This is where we start developing empathy and compassion for that other person.

Empathy and compassion

The majority of people I know are not bad people. They don’t wanna harm me in any way. So what are the chances that a colleague behind a chat message has bad intentions? I’d say pretty low.

By having a compassionate approach, we will think about that person first. For example, an approach to this disturbing chat message could go as follows:

Omg, look at this message of his. Imagine how hard it is for him, if he did not manage to find any other way to put it.

I need to understand this better.

By acting compassionately, you should have open questions only. Not assumptions and not your own evaluations.

Expressing the need. Requesting but not demanding

There is a reason why such a chat message is disturbing to us. It triggered some feelings of ours. And it is important to self-reflect on those feelings and understand the reason behind them.

Such feeling is usually connected to our own unmet need. We might need a simple thing like “desire to have harmony in the team”. You might realize that this is not happening in the team and start panicking or being frustrated. Therefore our need is not met, and we have an emotional reaction.

In order to resolve the situation to the end, the moment has come to approach our coworker.

The next steps in this little framework are to:

1. To express our own needs, and feelings, so that the request we are about to make, makes sense.

2. To make a request (but not a demand) to our coworker for what we believe will help us resolve the situation.

Here is an example:

Let’s analyze this a bit:

An observation without evaluation: Hey Delgado, I see that something is going on, and it seems there is more to say.

Expressing the feeling: By reading your message I’m a little disturbed.

Expressing the need: I would like for all of us to work in harmony.

Making a request, without demanding: I would love to get 30 minutes of your time on a call so we can talk about it thoroughly.

In summary

When faced with a difficult situation in communication with a coworker, the following steps will help you

1. Do not act impulsively. Wait, be curious and observe.

2. Assess the situation through compassion and empathy for others.

3. Self-reflect on your own feelings and unmet need.

4. Reflect on observation, express your feeling, state your need and make a request, without demanding.

This approach helps me in guiding and coaching my team members. And this isn’t something new. It’s an old method, which Marshal B Rosenberg explained in the book Nonviolent Communication. If you liked this post, then I’m sure you’ll like the book even more.

People expect rewards and they value security and certainty. In a less mature company, most processes are self-driven. At some point, your team will start asking important questions:

• How does the career ladder look for me?

• When could I expect a promotion?

And these are very important questions. They might be running on the same salary or title for years and they feel it’s no longer a fair relationship. Depending on how univocal your answers are, it will either set their peace of mind, or they will realize that the future is uncertain for this them.

Before we move on, let’s do a small exercise now. Choose a team member from your team and try answering the following question:

By answering this question, ask yourself - are the reasons for denying someones promotion based on your subjective opinion? If yes, you’re on a slippery slope. The team member you just thought about will challenge you, and you won’t have any counterarguments.

This is a pretty uncomfortable situation to be in. This person will lose trust in you, as they will perceive you as someone who’s wanna stop them in their growth.

So we usually have three choices:

• You won't promote anyone.

  This can work just for a while, but eventually, your peers will feel that they are operating on a completely different level and it'll come naturally for them to start asking questions.

• You will promote most team members.

  This is even worse, especially if they aren't ready for promotion. This is giving them a false understanding of their skills.

• You will explain why someone is not fit for promotion.

  Without any documentation or metrics, provided explanation is your subjective and biased opinion. Your peer can disagree and it's the end of the game. What follows is usually a loss of trust.

So you need an objective insight into the growth and performances of your team members.

Each one of us, especially in tech would like to know the following:

• current expectations

• career path

• projected salary growth

Expectations and competencies

If you're a startup, chances are that:

• You don't have levels per position defined.

• You don't have expectations set per level.

• You don't have competencies defined as well.

This limits how precise your performance review can be. That's because you can't say that someone is "above/below expectations". What if they ask "based on what expectations I am below"?

You will lose credibility. The importance of such a performance review is no longer relevant. Thus, you have to define a performance review, which is a bit flexible, because you don’t have a career ladder defined.

Set goals for your performance review

What is it that you want to achieve with the performance review? When defining the goals think of the following:

• At what stage of growth is my company?

• How mature is my team?

• Am I trying to solve some hidden problems with the performance review? Run 5-why's analysis here.

Five-why’s

1. My team is not growing professionally. Why?

2. They are not proactive in learning new things. Why?

3. They don't have time to do so. Why?

4. They are in a delivery mode with huge scope. Why?

5. Our sprints take too long. Maybe we should write more granular user stories and limit the iteration scope instead.

   Do I need a performance review just for this?

When I went in front of my team, these are the goals wanted to achieve with the performance review.

1. Presenting transparent promotion plans and compensation adjustments.

2. Set growth areas for every team member.

3. Tie compensation and promotion cycles to it.

4. Communicate underperforming aspects on time and out loud.

To the performance review!

In my team, we did not have expectations and competencies set. So we've come up with the following procedure for the performance review process.

Process

1. Every team member has to write down a self-review.

2. Every team member has to write two peer reviews. One for a close collaborator, and one for someone outside of his team.

3. The manager has to write his review for his peers.

4. The manager will sum up all documents and write down a final performance review

5. Schedule a performance review meeting with every team member.

6. Send performance review documents to your team members 24h upfront.

   This will make sure that everyone has the time to process the review emotionally and prepare the questions for you. 24h is a good offset. Not too early, not too late.

Document templates

It is important to control the narrative of the review process. To do that I have prepared document templates for each step.

These are the template documents we have used.

• Self-review template (team members to fill for themselves)

• Peer-review template (team members to fill in for others)

• Performance review template (for the manager to fill in for their peers)

Things to pay attention to

How you announce the performance review to your team is important

• talk about it on your one-on-ones

• don't send a too official email, as it'll boost the seriousness around the review process

• schedule an all-hands call on the topic of the performance review

• communicate performance review goals clearly

• communicate the review process in detail

• answer all questions honestly and openly

It's stressful for team members

If you are a manager, chances are that you don't perceive performance reviews the same way as your peers. They see it as a checkpoint. It will set their future in the company, based on what you tell them.

Reserve time for performance review

Your team members deserve objective and detailed performance reviews. You have to find enough time for writing each one of them.
By delivering generic performance reviews, the process will also lose credibility. This is especially important if you're conducting it for the first time in your team.

Set 'no blame' narrative

Even if some reviews won't be pleasant, use this opportunity to set the ground for improving and fixing things. Listing out deficiencies only, won't help.

Watch out for biases

None of us is immune to biases but we should be aware of them as much as possible. has a nice video on this topic. Some of the biases to look after:

• Recency bias - when we're under the impression of the most recent things that happened.

• Strictness bias - you shouldn't be strict with members you are not close with.

• Leniency bias - don't favor team members you communicate with often.

• Horns bias - if someone made a mistake once, that shouldn't flag them.

• Hallo bias - if someone made a fantastic achievement, it shouldn't mask their inefficiencies.

• Similarity bias - treat everyone equally. Gender, skin color, office location, and education can affect your judgment.

• Contrasting bias - Avoid comparing team members with one another.

Continuous feedback vs performance review

Opposite to performance review, some teams advocate for continuous feedback instead. To paraphrase one of my former team members:

As we're talking every two weeks on our 1-1s we can always discuss growth areas, as well as things to improve on. We don't really need a performance review for such things.

In essence, this is true. We do have regular one-on-ones and we discuss and plan the next steps and growth areas.

However, it’s important to understand that there is some “politics” in every company. HR and company leadership will expect some reports about your team members, that explain why someone is eligible for a promotion or salary raise.

Therefore, performance review has a two-fold value. One that is directed to the company administration, and another to our team. The latter is more important though.

In our team, we looked at performance reviews as a point in time. A checkpoint where we retrospect everything we already discussed in the past 6 months.
That's why, the performance review in our team wasn’t a surprise to anyone, as every topic we discuss during the review process, is already discussed in our one-on-ones.

Follow-up and cadence

Performance review conclusions must not be left aside. If you don't iterate on what you and your peers agreed on, then the review itself is pointless.
This sets you up for failure for the next review, as no one will see the value in it.

I am sure that many teams are conducting performance reviews in different ways. What did we do wrong here? Let me know in the comments, I’d like to revisit this approach.

It become quite challenging for me to find someone who did not experience burnout recently. Studies show that the most affected industries in the US are hospitality, manufacturing, and health care.

I could argue that the software industry is somewhere close.

People are wandering around, changing companies, getting divorced, going to psycho-therapy, fighting anxiety... All kinds of stuff.
Most of us do not realize what is going on until there is an obvious sign. Your body decides for you, or someone else tells you how fucked up you become.

I figured it comes with age and years spent working in the industry. Most people I talk with are in their mid-'30s or early '40s. Although my observation is biased, it perfectly falls into statistics.

"Millennials (those born between 1981 and 1996) are most prone to burnout.
Gen-Z (born between 1997 and 2012) is a generation with the fastest growing burnout rate."

This makes sense. '20s are hard. The '30s are a bit harder.

So what a hell is going on?

My wife, who isn't in the software, tried to provide her point of view - "the biggest problem with you (software people) is that you can always work."

This got me thinking. Is it that we CAN work always, or do we CHOOSE to work always?

The drive that you get by working and solving problems is pushing you. Dopamine hits. It's comfortable. We push each other. We all like it, and we don't mind long hours. Chatting about it until we go to sleep. It's a crowd behavior. I think we CHOOSE that.

But it's a hustle culture that you're served with.

Hey, you young person, everyone's expecting you to work more than 8h today, on weekends, remoting from vacation (just in case carying laptop wink-wink), but also be a solopreneur, and have a successful side gig. And a popular YouTube channel.

It's just too much work in an unbalanced way. When not working, we're thinking about it. When thinking about it we're distracted. People around you are uncomfortable when you're distracted.

Life

Intensity doesn't work well for us in the long term. We've seen what happens to people being stressed for decades. It just doesn't work well eventually.

We should be available for our family and be there for our kids. Thinking about yourself and longevity.
Most of this generation have some 25-30 years to retirement. We can't keep such intensity of work forever. And there has to be a change.

Change

Ask yourself - how do you wanna turn up to your family and friends tomorrow? Do you wanna have family and friends that you can turn up to in the first place?

I don't wanna be a distracted and busy, stressed person forever. This is a marathon and not a sprint. Nothing is ever finished. There are always new things to do, and it never ends.

With that in mind, we should optimize toward what's a steady pace.

Continually sprinting across the week -> having time with doing nothing -> recharge -> repeat.
That's not sustainable.

A change in relationship to work is necessary.

Work is part of life. Enjoying work is important. It should make us happy, build cool stuff, help others, being part of the community.

Yet, work is only part of life. Shrink that part down on a pie chart, to an important, but manageable part. Ironically you'll be even better at it.

Solution

It seems that managing energy instead of time provides good results.

Thinking in outputs throughout the week - instead of being obsessed to fill up every empty slot in our calendar with something "efficient".
Finding a steady pace  - optimizing for the long term. That's important.

It's a constant battle though, and I would like to hear from you, about your approach, techniques, or anything that helps you manage your energy (and time).

It's a bit provoking and bold statement and it feels counterintuitive. In a startup you can learn how to be a generalist and a pretty good one, so why the statement?

What does it mean to be a generalist?

Simply put, you know many things. Generalist is often described as a full-stack developer. I disagree. Full-stack as a subset of a generalist in the context of experience.

• frontend + backend (+ database) = full-stack

• mobile + backend (+ database) = full-stack

• frontend + mobile + backend (+ database) = full-stack

Generalists can cover much more: Infrastructure. Cloud. Data. CRM's. Databases. QA. Security. Backend. Frontend. Mobile...

I have been in on a technical interview, where I explained that I know mobile, backend, frontend a bit, AWS with Terraform, doing video courses etc.

Interviewer said: "So you're a full-stack."
I said: "No I'm not. I am mediocre at many things however my skills are best at mobile and backend."

What does it mean to be a specialist?

Well, you specialize in one thing only.

• I am an android developer - says you have specialized in android only.

• I am a data engineer - says you do nothing else but data-related architecture and development.

• I am a .NET developer - ...

You get the point.

Which one is better?

Let's look through the prism of how much experience you have.

• If you just started your career - be a generalist.
  You need to learn as much as possible from as many different fields. Truth is, usually, you won't be that generalist.
  As you land a new job, you'll focus on being the best you can at that one thing you're working on. It's up to you to be curious and explore many other things you could be working on.

• Once you accumulate a couple of years in the industry, you have the luxury of specializing in something.

But here is the trick - specialize at multiple things, not just one. This is what is called Generalizing Specialist.

In the software industry nowadays, you don't wanna limit your opportunities by knowing one technology too damn good. Find your niche, expand it a bit and specialize. It helps with the identity of the company as well. Eventually, you'll be more wanted, and more expensive.

In his series of tweets, @thiagoghisi is talking about this and described Generalizing Specialists as "Jack of MANY Trades and Master of SOME".

I think that such a description fits perfectly. A warm suggestion to go and read the whole twitter thread.

So, why "avoid" startups early in your career?

Usually, early-stage startups are rushing to make something useful, as they are constantly running out of money. In this critical period, you'll be on your own more or less, while you could really use proper mentorship and guidance.

Therefore, seek for good mentors to guide you through the wood until you look at the green field.

You can form a diamond only once. Therefore, there is no greater danger for someone who is fresh in the industry, than to learn things in the wrong way and to be mediocre at everything.

What is causing impostor syndrome?

❗Disclaimer:
Impostor syndrome is a psychological state and I'm not a domain expert. I just learned how to overcome it by myself.

It was when I started freelancing that I experienced the impostor syndrome for the first time. I had to find my own clients and the thought that there is something I don't know caused me to panic.

In my mind, that's because "not knowing something" leads to "not being able to implement something". Which leads to "client will notice and end the contract".
At the end of the day, I'm gonna be incapable of providing an income for my family.

Impostor syndrome is especially widespread in software engineering. There are so many tools. So many programming languages. Countless ways to do the same thing and we don't know all of them.

Naive solution for impostor syndrome

To me, impostor syndrome surface when I figure that I don't know something - new.
Since that's the case, an obvious solution is to - Learn what you don't know.

In the short-term, that's good. You'll expand your knowledge and feel good. Yet, we forget that the more we learn, the more we discover how little we actually know.

It spirals down without control and the impostor kicks in more often and harder.

Social networks and interactions have an enormous negative effect

Scenario #1:

My mind:

- How is it possible that I hear about this for the first time
- Am I wasting my time on irrelevant things, while others are improving their knowledge.
- Who knows how many other things I don't know.
- I am plain stupid for this job.
- How did I even make it so far.
- I hope no one will notice that I don't know this.
- Quickly, let's learn all about it and go back to that discussion to show that I'm worthy as well.

Reality

As you learned something new, so did your colleagues. They wanna share that and ask for feedback, as you do.
There are hundreds of things you know of, that they haven't heard. But that's not the point.

It's completely ok not to know everything, or not to be first that's informed. Chill.
When the time comes, you'll take a couple of hours and go through unknowns. Even better, you now know whom to ask for help.

Scenario #2:

My mind:

- If I don't learn this new thing in 5 days, I'll be out of job in 6 months.
- There are so many libraries and architectures I still don't know.
- How can it be that other know all this stuff, am I late to the party?
- How did I even graduated CS without knowing this??
- I should accept I'm not fit for this job. I'm just pretending to know something.
- I am a fraud.

Reality

Development tools and libraries are also business as any other. Developer advocates are paid to talk about brand new things. It's a sales process, and you are the buyer. Conferences are organised, meet-ups. Adoption of new library, or programming language will determine the future of specific technology and its company.

I'm using social networks to learn and expand my knowledge. In such a process, I discover many smart(er) persons with lots of accumulated knowledge.

Instead of learning from them, I start asking myself "why don't I know those things as they do".
Again, it's a downstream spiral without an end.

Awakening

An awakening moment happened to me a couple of years ago when I was reading about another new thing. At one point, it simply made no sense anymore. Every month, something extraordinarily new. How can it be!?

We're using "A", adopting "B" and now you're telling me that "C" is actually the best and "D" is in the canary line already? Oh come on!

That's when I could sit and see with my open eyes for the first time.

• "A" is working for decades.

• "B" is working for a couple of months

Either of those will do the work. And I know both of them. I picked up "B" quickly. Actually, it took a couple of days.

So I'm not stupid. I'm not a fraud. It's the hyper-production of all new technologies that is happening and we as software engineers are victims to it.

How to control Impostor?

Impostor syndrome will kick in from time to time. That's inevitable. When it does, be wise and say to yourself:

• This new thing - is it so urgent that I should pick it up today? - I can tell you straight away - not really.

• Will I become obsolete if I don't learn this new technology? - No you will not, trust me.

• Everyone's losing their mind about this new thing. Should I? - No, let them test it and you wait for a stable release. If you're curious about it, sure, go ahead and explore. But usually, you're just a beta tester and that thing will change by the time it goes to a stable track.

• How come I never heard about X? - That's fine. You have it now, thus you're not late.

Dear reader, listen,

You came to this point of your career only with your accomplishments. No one did it for you.
Retrospect and see how long does it usually takes to go through some new fancy thing. It's days. In worst case, it's weeks to pick-up and start working. Thus, why worry.

We all start running at different time and it's normal for some to collect more experience. Yet, as time goes on, that experience and knowledge will converge.

When does the magic happen?

By saying "I don't know, can you explain this to me please?" That's when you can call out a complete victory over Impostor.

There is no shame in admitting that you don't know something. What's more, it'll show others that you're just like them, because they are fighting the same battle. Just watch how the magic unfolds with your colleagues when they admit they don't know it either.

A side-effect of this is the reduction of your own ego. No ego = supportive team culture. And I think it's beautiful.

In fall 2021, AWS introduced an extra S3 storage class - Glacier Instant Retrieval. This brings us to a total of eight S3 storage classes offering different upsides.

• Standard

• Standard Intelligent-Tiering

• Standard Infrequent Access (IA)

• Standard One-Zone Infrequent Access

• Glacier Instant Retrieval

• Glacier Flexible Retrieval

• Glacier Deep Archive

• Outposts

S3 Glacier Instant Retrieval

Let's say you have had an object which requires real-time access. Depending on how often you access it, you would choose some of the Standard storage classes. Usually Standard-IA.

Glacier storage classes are used for archive purposes. If you don't want to delete the object, but still want to keep the option of accessing it (in no real-time), you would use Glacier.

Glacier Instant Retrieval is a missing link between cheap storage and real-time object access.

Standard classes offering:

• realtime access

• expensive storage

• cheap data retrieval

Glacier classes offering the opposite:

• no realtime access

• cheap storage

• expensive data retrieval

Glacier Instant Retrieval offers the best of both worlds:

• realtime access

• cheap storage ($0.004/GB - 3x cheaper than IA)

• affordable data retrieval ($0.03/GB - 3x more expensive than IA)

Adjusting lifecycle rules to Glacier Instant Retrieval

In November 2021, I wrote about optimizing S3 storage costs where we made a cost-cut of $40k annually.

In bucket analytics, you can see a couple of important parameters.

StorageClass
ObjectAge
Storage_MB
DataRetrieved_MB
ObjectCount

By applying the same principle, but now based on December data, I've come up with the following calculation.

In this case, I am calculating the difference between Glacier Instant Retrieval and Standard-IA, by comparing storage costs and data retrieval costs.
As expected storage costs dropped significantly, while data retrieval costs are negligible.

The conclusion is obvious:

By moving the objects to the Glacier Instant Retrieval instead of Standard Infrequent Access we can save 60% more on top of cost-reduction we already made.

Let's do it!!

➡️

A spreadsheet with real-world data is available here. With minor adjustments, you can use it to do your own calculations.

S3 IA vs S3 GIR: Cost analysis spreadsheet

Why it works in the case above?

• We have a small number of objects (around 100k long-lived, rarely accessed objects.

• All our objects are huge - a couple of dozens of GBs.

• We access these objects 2-3 times in a lifetime before it is a candidate for Deep Archive transfer.

When does it not make sense to switch to Instant Retrieval?

• One downside of Glacier storage classes is that you have to keep objects in storage for 30 or 90 days. If you delete the objects - a pro-rated charge applies anyway.

• If your storage is huge and you have small-size files (a couple of hundreds of kB), it means you'll have millions of files in the bucket. Pay attention to lifecycle transition cost, as it might be more expensive to move objects from one storage class to another than the cost is made.
  For example:
  - To move 1000 objects into Glacier Instant Retrieval, you'll be charged $0.02.
  - To move 15m objects to Glacier Deep Archive will cost $750.

• If you're accessing objects at least once a week (or so - it depends on the object size), it most probably makes sense to leave it in Standard IA.
  

It's beyond belief that AWS is introducing these optimal storage options. We have reduced our S3 monthly costs from $3400 a month to $300 a month.

Therefore, if you have large storage, and you wanna keep those files - it's worth paying attention to different storage class capabilities as we did.

✅

If you've liked this post, make sure to subscribe down below. I am mostly writing about engineering management, specific software development stuff, and cloud services.

We are a distributed team, in a startup company, working on software development for in-house products. Our team consists of product managers, product designers, software developers, QA, SysOps, etc.

We used Notion for four months and switched to Jira. Below is the explanation why.

Let's start with Notion.

When the team got invited to Notion, it looked like a "known tool". Soon, it was obvious that the rest of the team had no clue how Notion works.

Whole Notion works around three to four top-level containers:

• Database

• Page

• Subpage

• Template

Database - You can imagine the database as a spreadsheet. You add columns and define its labels and data types (called properties in Notion)
Page - One database can have many pages. Actually, every entry into the database is a page. Page can exist outside of the database as well.
Subpage - Subpage cannot exist without a page. It's a classic parent-child relationship.
Template - Well, it is a page template, and it links to a database.

Upsides

Flexibility.
You can define databases and shape them for every need. Todo list. Project tickets. Countless existing templates to reuse and save time.
Easy to organize documentation with a powerful text editor.

Filtering.
An advanced feature. You can create a "view" on top of the database and set up a filter for that view only, without affecting anything else.

Custom templates.
Countless, very useful and nice-looking page templates are available. What's more, you can define your own, and save time when creating "tickets" (read: pages).

Downsides

Filtering
Although listed as an upside, this is where Notion is a bit harder to understand. What was the challenge?

• You can create views on the database, and apply the filter on a view.

• Editing a view filter and other setups don't affect the database.

• Editing the page inside the database will apply the change across all views.

• Setting up the filter on a database will affect everything.

Our team struggled to differentiate view from a database.

In our setup, we had a personal page for everyone called "My tasks". That was a view on top of the database, filtering by assignee property.
And that worked. However, we needed some custom filterings all the time. Due to difficult understanding, most of the team members used filtering options on the database level instead.

By applying the filtering option on a database, you'd affect the whole system. Every view, and how the database looks like for everyone else would change all the time.
We had this issue at least three times a week. As time passed by, it become a joking topic in the team, followed by a rant.

As a Director of Engineering, I have started asking myself. How many times we lose focus, started ranting instead of working. Why isn't this tool serving its purpose? Are we using it in the wrong way?

Permissions
Very high-level permissions are available.

The product will evolve for sure. But not being able to set permission on "who can change database schema" is a huge problem.

Why? Someone clicked on a database and accidentally (or not) added a new property. This property shows up on every view, for everyone.

We could argue that "it's great how flexible it is"? Well, NO. As a product manager or project manager, we have no control over how to manage tasks, nor processes if everyone is intervening.

What's worse, you can delete the property as well. This is where things started to go south.

Isn't there a better way to start your Monday than to face a Notion database with the "Project" property removed?
We noticed this after 2-3 hours of work. Every filter everywhere is affected. Thousands of tickets mixed. There is no non-destructive way to revert the change.

A team member that made the change, reverted the version of the whole database out of panic, effectively canceling 3hrs of work for the team of 40.
There is an option to lock the database though, but it's not efficient, as you have to unlock it and lock it many times a day.

There was no permission to set to at least prevent:

• database property removal

• database restoration process

Workflow

As with any other ticketing system, you'd have a ticket status. In the case of Notion, it's a property "Status". A single-select data type, with values such as "Backlog", "To do", "In progress" etc.

Our views were set around the "Status" property, so we have had a board of tickets with these columns. What proved to be a problem for our team is the actual flexibility on where you can move the ticket.

In Notion, you can move it anywhere. I have spent so much time explaining the ticket flow.

From "In progress" ticket has to go to "QA".
Then from "QA" to "Done".
From "Done" it would end up in "Deployed" and "Closed".

Closed means, it's in production and tested/verified.

So often, developers would move the ticket from "In progress" to "Done", or even worse to "Closed".  This was causing so much confusion, untested tickets, communication overhead over a single ticket.

Notion conclusion

Fantastic flexibility came with a price for us. I was spending 10-20% of my daytime communicating with team members how to use Notion.
Fixing filters, views, adjusting permissions, etc.

I even organized a "Coding Friday" with a topic: "How to use Notion". All with examples and differences between database, view, page, and template.
Without special positive outcomes.

Team frustration caused some team members to start using Github issues in parallel. Then they would sync (manually) Notion to be in the same state as Github.
This was a deal-breaker already. Imagine how inefficient this was. The tool should help us, and this wasn't happening.

It is a great tool for documentation. Its text editor is state of the art. Organizing pages, subpages, embedding external content is fantastic. Public exposure of single pages is so useful. When you have to present something to team members without a Notion account, it's a click away.

Pricing is questionable. Besides the tech team, other team members started applying, and quickly we had 100 accounts. Cheaper subscription packages on Notion have limitations.

One that I disliked is the number of "timeline views" (read Gantt charts) you can create. Come on. I'm trying to create a view, trying to organize myself and you're limiting the number of views ??

All in all, it was a cost of $10k a year for a tool that wasn't too efficient for us.

Jira

We needed a ticket management tool. By running a quick poll on Slack, Jira turns out to be a tool everyone worked with before.

I've exported all pages from Notion into CSV. Through Jira importer mapped the Notion properties to Jira fields and run the import. In a matter of hours, I had a setup in Jira which we used for tracking the progress of development.

Upsides

Workflow
By setting up the workflow of the tickets, all that communication overhead such as "where this ticket should go", disappeared.
The tool is serving its purpose. It is helping the team to do their work, without thinking of "how to use ticket management system".

Automation
Jira automation is making things even simpler and no one needs to think of "to whom from the QA team to assign the ticket".
Jira will do it, because someone already thought about it and set it up.

Github
Integration with Github makes it so easy to navigate back and forth. Impossible with Notion.

Team satisfaction
To an engineering manager, it's relieving to see the team happy. This change motivated the team, as they no longer have to struggle with simple tools.

Price
We are using Standard subscription. Together with the Confluence subscription, it still costs us less than Notion subscription on an annual basis. Worst case, it'll cost the same.

Downsides

Complexity
Jira is rather complex to set up. All the issues, types, projects, permissions, screens, schemes, fields, and whatnot. It is a time consuming to set it up.
I was relying on default setup for new projects, while I was setting up reusable setup in the background.
Once the reusable setup was ready it was a matter of few clicks to connect it with all projects.

Less flexible
Well, this week I googled "How to support product backlog and sprint backlog in the same project in Jira". It turns out it's a hard thing to achieve.
In Notion, it would be a matter of adding a "label property" and filtering with it.

Expensive additions
It's the same with all other products. As Notion puts limitations around subscription levels, similarly to use some advanced plugin with Jira (like BigPicture) might double the cost of a ticketing system.

Conclusion

Notion offers flexibility and powerful documentation options. It is not a ticketing system.

Jira + Confluence = ticketing + documentation, system.
Confluence also offers plenty of templates and a powerful editor. It lacks public exposure of pages as a downside.

The decision point was the efficiency of the team. Jira helped and we're happy with it.

AWS Cost Explorer

We are hosting most of our services on AWS. Thus we've opened the Cost Explorer and started with a simple cost analysis. Three services popped up as obvious budget drains:

• RDS

• S3

• ECS

We have figured that it'll take more effort to optimize something on RDS and ECS, compared to S3. That's how we came to the conclusion, that we have a quick win by focusing on S3 first.

S3 cost segmentation

By tweaking the filters on cost explorer, we come up with the visualization of S3 costs. The main driving factor in storage high-cost is actually storing the data.

We store video files, so the high cost doesn't come as a surprise. Yet, it was too much.

S3 storage classes

We assumed that our objects in S3 buckets aren't in a proper storage class. For those unaware of this, S3 supports the following storage classes.

• S3 Standard

• S3 Intelligent-Tiering

• S3 Standard IA

• S3 OneZone IA

• S3 Glacier

• S3 Glacer Deep Archive

• S3 Outposts

Each storage class has its own specific pricing model. If you want to deep dive into the details, make sure to read about it here.

To sum up:

• S3 Standard has the cheapest object access and transfer prices. But, it has the most expensive storage per GB price. It is used for frequent object access on a daily basis.

• S3 Standard IA is a middle ground. More expensive object access and transfer, but a bit cheaper storage price. Usually used for infrequent object access.

• S3 Glacier and S3 Glacier Deep Archive are used for archiving the objects. Realtime access to objects stored in these classes is no longer possible.

We could not find out any addditional details and we had to move to S3 itself and continue with analysis.

Storage lens

The storage lens dashboard is accessible from the S3 service homepage. Once we opened the dashboard, it was a surprise how our data grew over time. 180TB and counting.

By exploring different options in storage lens, we have discovered three outstanding buckets. 110TB, 50TB and 20TB, respectively. But that was the best we could find out at the moment. To make a proper decision on what to do with this enormous set of data, we needed deep-level bucket analytics.

Storage class analysis

To get a detailed bucket analysis, we have created a new analytics configuration. It has to be set for each bucket individually.

1. Open target bucket and select Metrics tab. Under the "Storage Class Analysis" section, choose "Create analytics configuration" option.

2. Define configuration name and choose options as on the following screenshot.

Note: Even if you don't plan to do any S3 optimizations soon, turn on bucket analytics today. You will gather valuable information throughout the year. Based on this data, you will make a final decision on how to optimize S3 costs.

Object usage analysis

Once you open the analytics file in the spreadsheet, you can see a couple of important parameters.

• StorageClass

• ObjectAge

• Storage_MB

• DataRetrieved_MB

• ObjectCount

What are we looking at first? We want to know how often we access S3 objects. DataRetrieved_MB and GetRequestCount columns will tell us that. What's more, we have that information segmented by ObjectAge.

You can see example analytics for one of our buckets.

It is quite obvious here, that system is accessing objects in first couple of days of object life. After that, objects are not used anymore.
What's unfortunate for us, is that all objects are stored on the S3 Standard storage class. This one is the most expensive one for storing objects.

Optimization steps

Common sense is telling us that we have two options:

• Delete all objects older than 14 days

• Move all objects older than 14 days to Glacier Deep Archive

Before we validate those options, we have to look at other cost influential factors.

Transfer costs

When you're moving files from one storage class to another, you're paying a transfer fee. The most expensive destination is Glacier Deep Archive. It costs $0.05 per 1000 requests.

What you have to do then, is to look at the ObjectCount parameter and see how many objects you would have to move. That's how many transfer requests you will have. To save money in the long term, you have to pay something upfront.

Glacier meta-files

To store objects to Glacier Deep Archive, S3 creates metadata files. These files provide information on objects in deep-archive. For each transferred object to Glacier, S3 creates two more objects. One of 8KB in Standard class and one of 32KB in Glacier class.
Why is this important? If you have a huge amount of objects in the bucket, with a small object size (in KB), it is possible that you'll never have a positive break-even point for cost-saving.
It turns out that you might be spending more money on transferring the objects, than saving on storage.

In our case, that wasn't the case, and we moved on with the initial plan. We will move all files older than 15 days to the Glacier Deep Archive storage class.

How to do that?

Lifecycle rules

What's great about S3 object transfers is that you don't do it by hand. Instead, all we need is to set a lifecycle rule which moves the files automatically based on object age.

To set lifecycle rule:

1. Go to bucket "Management" tab

2. And choose an option "Create lifecycle rule"

We have set a rule action that applies to all objects in the bucket, as follows:

And that's all it takes. From now on, every object older than 15 days will transfer to Glacier Deep Archive.

More complex scenarios

The bucket we used in the above example is not that common. Usually, object access happens throughout the year instead of the first two weeks. In another bucket example, we have set the lifecycle rules as follows:

1. After 30 days move files from "S3 Standard" to "S3 Standard IA".
   Because in the first 30 days, 80% of work on those objects completes. That's why S3 Standard Infrequent-Access fits in, as it's cheaper to store, but still provides real-time access.

2. After 18 months move files from "S3 Standard IA" to "S3 Glacier Deep Archive".
   After 18 months, the object won't be available in real-time. Someone still might ask for that file. If that happens, they will have to wait for 12h to restore it from Glacier. It's a tradeoff we made with reduced storage costs.

Result

With this simple approach, we reduced S3 costs seven times, saving ~$40k annually.

Throughout the years, the engineer gets promoted. At some point, you become a team lead and stay in that position for some time. The biggest responsibility is to keep the high-quality bar in the team. It is usually reflected through code, architecture, and mentorship of younger team members.

Delivery of good results brings benefits and you get into the position of leading the whole project. The stakes get bigger. Less time spent on coding, but more on communication with product managers, customers, guiding team members.

And you are getting better and better, so you get an offer to be an engineering manager. Naturally, you accept, without fully understanding what does it mean for you.

What is an engineering manager?

First and foremost. Software engineer, that become engineering manager, is not promoted. It is a transition from a technical role into a managerial role. A career choice has been made that is no longer technical. After a decade of work, you're in beginner's shoes again, googling this article eventually.

It's completely fine to ask yourself then "What should I do?".

If you have someone to show you direction and mentor you, consider yourself lucky. Because 14 out of 15 engineering managers are coming from the software development shoes, without any support provided by the company or upper-level management. So, don't be too stressed, your company is no different.

Engineering manager roles are different from one company to another. When I got promoted, I have tried to find a precise definition of my new role. And I failed. I will try to describe the most common things, you will do as an engineering manager.

You have the team

The engineering manager has a team of up to 10 people. Ideally less. Depending on the team topology in the company, your whole team is usually working on the same project.

Your team is here to stay. Even if the project change, team members won't leave the team, because you have established a trusting relationship already. That is crucial for your ability to help your team members.

Trust

The main driver of a successful engineering manager is establishing trust with its team members. It's easier said than done. Trust is not assumed, it has to be earned, and it takes time and skill to do it.

As a promoted engineering manager, you have a much easier job, as you worked with the team for quite some time. Take that as an advantage. Communicate openly and make sure to show by example that nothing is strange now with you in a different role.

Therefore, your first task is to schedule recurring 1-1 discussions with every team member. The optimal recurrence is once every two weeks.

Don't mix trust with friendship. When approaching 1-1 discussion, it has to be driven on a professional level. Avoid beer-like discussion and leave it for the more appropriate time.
Closest metaphor would be, when you say to your partner "Can we take a sit, we gotta talk?". So, you still love each other, but you're still having a serious conversation.

Growth

Having team members not improve their skills is a failure of an engineering manager. You should set the goals together with every team member. Support them in achieving those goals, by providing resources and connections with other experts inside or outside the company.

Performances

Your output, as an engineering manager, is just partially your personal achievement. What is measured is the output of your team actually. If the team is not performing well, it's a clear sign that something is off with your approach.

Performance reviews are done at least twice a year. In some companies every quarter. If you don't have them yet, start planning.

Supporting software development

Since most engineering managers have great software development knowledge, it's natural for them to get themselves involved in the technical decisions or at least discussions.
If possible, don't, as there are other team members in your team that have the accountability of making a technical decision.
Some high-level technical decisions are ok to be part of. I like to help the team with better version control, release cycles, deployment strategies, etc.

You as an engineering manager will constantly communicate with the product manager as well as with the manager you report to. Often communication provides a better perspective over business needs. What comes from that is the understanding of how a team effort can help those business needs.

Apart from the technical part of the process, applying software development methodology like Scrum requires additional involvement as well. Being in contact with the product manager to plan the next features is out of greatest importance.

Hiring

An important role of the engineering manager is to help with talent recruitment and hiring new team members. Therefore you will have to have open communication with your recruiter all the time. Checking new candidates and helping with the selection process every day. This will help in the better shortlisting process and optimal interviews.

You will have to organize interviews, and set general rules on how one interview should look like. Make sure to repeat constantly what to communicate to candidates and how to present company benefits in an easily understandable way.

After the interview, there is an onboarding stage. If it doesn't exist, it's up to you to define one. If it exists already, you have to make sure that the onboarding is improved with every new candidate. It is a never-ending process.

Firing

The most uncomfortable part of this role is when you have to fire someone from the team. It's impossible to be good at it if you're just starting as an engineering manager.

Take all of the help you're offered with. Value every piece of advice.

What engineering manager is not?

Usually, engineering managers do not code. Not many software developers are ready to make a full transition into management in a single day. That's why I suggest having the coding option open for really small tasks.

Set the goals for engineering managers, so that they don't fall back to the safe heaven of coding by default. Coding should not slow down education and the advancement of a manager.

The engineering manager is not a psychiatrist. If you are not an educated one, and chances are you aren't, don't try to be one. We might face team members in a difficult period of life. The best thing to do is to listen and be there for them.

Where to start

Start reading. Here are a couple of books (in order) that helped me to start my thought process on engineering management.

Become an Effective Software Engineering Manager: How to Be the Leader Your Development Team Needs

The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change

Team Topologies: Organizing Business and Technology Teams for Fast Flow

Check for blogs of other engineering managers. One of my favorites is Gergely Orosz.

There is a whole community of people helping each other in these roles. You wont have to search for them, because this community is just exceptional.

Closing note

I am currently in the position of Director of Engineering and will be writing about engineering management challenges. If you liked this post, hit the subscribe option below and get more content in the future, based on personal experience.

U Republici Srpskoj to je moguće na dva načina.

• Osnivanjem d.o.o (društvo sa ograničenom odgovornošću)

• Osnivanjem SP (samostalni preduzetnik)

U daljem tekstu ćemo se baviti SP-om, koja je procedura za osnivanje, koji su troškovi i kako se računa porez na dohodak.

SP - D.O.O

Prvo pitanje koje se inače postavlja je, koja je razlika izmedju D.O.O i SP?
Osnovna razlika je u tome što sa SP u slučaju nekog spora odgovarate sa ličnom imovinom, dok u slučaju D.O.O. odgovarate visinom osnivačkog kapitala.

SP je mnogo brže i jeftinije registrovati (isto tako jeftino i ugasiti), te je većini freelancer-a za početak sasvim dovoljan.

MP/VP, a ustvari SP

Kada se govori o SP-u, prvo će vam neko pomenuti famoznu cifru of 50.000KM.
Radi se o sljedećem:

• Ukoliko u toku godine vaš promet ne pređe 50.000KM, vi ste mali preduzetnik (MP).

• Ukoliko u toku godine vaš promet pređe 50.000KM, vi ste veliki preduzetnik (VP).

Šta to praktično znači, pogledajmo kroz troškove.

Troškovi

• Mali preduzetnik (MP) plaća porez na dohodak od 2% (a minimalno 50KM mjesečno). Ovo se još naziva i paušalni porez.

• Veliki preduzetnik (VP) plaća porez na dohodak od 10% i ulazi u sistem PDV-a. Dakle, sa svojim pravnim subjektom možete imati milionski promet, a i dalje biti SP.

• Vi kao vlasnik SP-a, za sebe plaćate doprinose (PIO, zdravstveno osiguranje itd) na mjesečnom nivou. Iznos doprinosa se računa na osnovu prosječne plate u Republici Srpskoj za prethodnu godinu.
  Npr. Za 2020-u godinu, prosječna bruto plata je bila 1485.00 KM, a računica izgleda kao na slici ispod:
  

Dakle, mjesečni iznos doprinosa koji morate platiti u 2021 godini je 292.00KM (upamtite ovu cifru).

• Komunalne i republičke takse, razne naknade na godišnjem nivou koštaju oko 200KM.

Dakle, ako ste osnovali SP i još uvijek ste mali preduzetnik, mjesečno ćete imati minimalno: 292 + 50 = 342 KM troskova, jer je paušalni porez minimalno 50KM, kao i jednom godišnje plaćanje pomenutih naknada.

Ukoliko ste veliki preduzetnik, paušalni porez ne plaćate, već samo doprinose i godišnje naknade.

Kako se računa porez na dohodak

Najbolje je da krenemo sa primjerom. Recimo da ste u toku mjeseca ukupno naplatili 3000 KM. Porez na dohodak se računa tako što:

1. Od preostalog iznosa iz prvog koraka se računa iznos poreza.
   U slučaju MP: 3000 * 2% = 60
   U slučaju VP: (3000 - 292) * 10% = 270.80

Dakle, ukupni troškovi koje ste dužni platiti poreskoj upravi u gornjem primjeru su:

MP: 292 + 60 = 352.00 KM
VP: 292 + 270.80 = 562.80 KM

Tako da vam na raspolaganju ostaje:
MP: 3000 - 352 = 2648.00 KM
VP: 3000 - 562.80 = 2437.20 KM

PDV

Vrlo je bitno da znate, da ukoliko svoje usluge fakturišete inostranom klijentu, to što ste kao veliki preduzetnik u sistemu PDV-a BiH ne igra nikakvu ulogu, jer pravno lice kojem fakturišete NIJE u sistemu PDV BiH.
Samim tim, PDV ne fakturišete inostranom klijentu, tj nemate izlazni PDV i isti ne plaćate.
Dakle, ukoliko ste u sistemu PDV-a i fakturišete inostranom klijentu, primjenjuje se računica iz gornjeg primjera.

Ukoliko svoje usluge fakturišete pravnom subjektu registrovanom u BiH, na cijenu vaše usluge se dodaje PDV od 17% i tako uvećana faktura se šalje klijentu.

Kako većina freelancer-a radi sa inostranim klijentima, prelazak u sistem PDV-a ne predstavlja nikakav problem.

Ono što je bitno da se napomene. Svake godine do 31.1 u poreskoj upravi se mora podnijeti zahtjev za MP status. U suprotnom isti nemate te vam se status mijenja u velikog preduzetnika.

Prednosti i mane

Zašto biste osnovali SP?

• Zdravstveno osiguranje, staž.
  Ukoliko ste do sada radili kao freelancer i vršili naplatu preko raznih payment servisa, deviznog računa u banci itd, bili ste u obavezi da platite porez od 10% na isplaćenu sumu i to je to.
  Kroz poslovanje sa SP-om, zdravstveno osiguranje sebe i svoje porodice uplaćujete na mjesečnom nivou, a iznos poreza je manji (MP = 2%) ili isti (VP = 10%) nego kada ste bili u sivoj zoni.

• Lakoća poslovanja.
  Kada imate osnovan pravni subjekt, potpisivanje ugovora sa drugim pravnim subjektima je stvar forme i vi vrlo lako ulazite u poslovne odnose sa drugim pravnim licima. Mnogim pravnim subjektima, naročito na lokalnom tržištu nije povoljno da posluju sa fizičkim licima.

• Prepustite knjigovođi.
  Obračun poreza, doprinosa, plaćanje istih i svih nekih zakonskih zavrzlama i naknada za koje ne znate da postoje treba da prepustite knjigovođi da se o tome brine. Usluge knjigovodstva su od 50 - 150 KM mjesečno.

• Odbitak.
  Ukoliko ste veliki preduzetnik, imate mogućnost odbitka od poreza kod nabavke opreme. Laptop, internet, kafa, monitor, su sredstva koja vi kupujete da biste uspješno prodavali svoje usluge. Troškovi koje imate zbog nabavke svih tih sredstava se odbijaju od poreske osnovice. Kao mali preduzetnik, ovu mogućnost nemate.

Šta SP i dalje ne riješava?

• Poteškoće naplate preko PayPal-a, UpWork-a itd. Većina freelancer-a radi putem UpWork-a i sličnih platformi. Vi kada radite za klijenta kojeg ste našli putem UpWork-a, najčešće nemate ugovor i ne šaljete mu fakturu. Kada vam zarađena sredstva budu isplaćena vi nemate na osnovu čega da opravdate porijeklo tog novca.
  Zato se preporučuje da se klijenti sa kojima se radi potpiše ugovor ili da im se izda faktura, kako biste istu mogli predočiti banci u trenutku kada vam zarađena sredstva budu isplaćena.
  Praktično je nebitno odakle se sredstva isplaćuju (PayPal, Payoneer, Wire itd) dok god možete dokazati porijeklo novca.

• Nepovoljan položaj u banci kada vam treba kredit.
  Desiće vam se da zarađujete vrlo lijepo, hoćete da kupite stan i odete u banku da podnesete zahtjev za stambeni kredit. Neprijatno ćete se iznenaditi, jer će vas u banci smatrati vrlo rizičnim klijentom.
  Što se banke tiče, budžetski korisnik sa minimalnom platom od 500KM će lakše dobiti kredit nego vi koji možete imati primanja od nekoliko hiljada KM. Da biste ovaj problem prevazišli, prvo morate znati pregovarati, drugo morate znati svakoga, i treće tražiće desetke i desetke potpisanih papira i izjava.

• Zbog niskog praga prelaska u PDV sistem, vrlo brzo ćete postati skupi lokalnim klijentima. Dakle, da biste pokrili trošak od 10% + 17% PDV-a, vi ćete dići svoju cijenu i biti u nepovoljnom položaju u poređenju sa onima koji rade na crno, te naposljetku izgubiti poslovnu priliku, jer pokušavate da radite pošteno dok drugi to ignorišu.
  U zemljama regiona, samo Crna Gora ima niži prag ulaska u PDV od Republike Srpske.

Postupak registracije SP-a u Republici Srpskoj

Prvi savjet je da to prepustite knjigovođi da vam riješi, ukoliko pak nećete, postupak za Banja Luku je otprilike ovakav:

1. U opštini u sobi broj 21 imate besplatnu službu za savjetovanje, gdje će vam ljubazno osoblje sve objasniti.

2. U osnovnom sudu je potrebno da podnesete zahtjev za uvjerenjem da nemate neplaćenih kazni. (čeka se par dana)

3. U osnovnom sudu je potrebno da podnesete zahtjev za uvjerenje da nije izrečena pravosnažna presuda zabrane obavljanja djelatnosti.

4. U poreskoj upravi je potrebno da podnesete zahtjev za uvjerenje o plaćenim porezima. (čeka se par dana)

5. U opštini je potrebno popuniti zahtjev za registraciju preduzetnika. Ponovo, osoblje iz sobe 21 će vam tu pomoći.

6. Zajedno sa tim zahtjevom i uvjerenjem iz suda i poreske u sobi 16 na šalteru 1 i 2 se podnosi zahtjev za registraciju. Ovde se plaća par taksi (cca 30KM). Na rješenje od registraciji se čeka oko 3-4 dana.

7. Nakon što je rješenje o registraciji gotovo, zovu vas na telefon te isto idete u opštinu preuzeti.

8. Sa rješenjem idete kod pečatoresca da vam se napravi pečat. (čeka se par sati, u zavisnosti od vrste pečata plaćate jeftinije ili skuplje, cca 30KM)

9. Kada dobijete pečat, idete u poresku upravu te podnosite zahtjev za izdavanje JIB-a (za ovaj zahtjev vam je potreban pečat) (čeka se 3-7 dana)

10. Kada dobijete JIB u poreskoj upravi, tada idete u banku da otvorite poslovni račun. Kako ćete najvjerovatnije raditi sa inostranim klijentima, odmah naglasite da vam se otvori i devizni račun (čeka se 3-4 dana)

11. Po otvorenom računu u banci, idete kod knjigovođe i potpisujete ugovor o saradnji. Nivo ovlaštenja koje ćete dati knjigovođi je vaš izbor. Knjigovođa može da ima pristup vašem bankovnom računu i da plaća sve umjesto vas ukoliko vi tako odaberete.

12. Naposljetku idete u poresku upravu da se prijavite i možete početi sa radom.

Iz ličnog iskustva, proces osnovanja SP-a u Banjoj Luci traje oko 30 dana.

Knjigovođa

Ukoliko ste mali preduzetnik i znate da sami izračunate poreze i doprinose, knjigovođa vam manje-više i ne treba. Međutim, postoje razne naknade kojih niste svjesni, npr “Vodoprivredna naknada” od 6KM… sa druge strane, pošto sa SP odgovarate svojom imovinom, ne želite da se dovedete u situaciju da vam poreska šalje opomene zbog propuštenog plaćanja.
50KM mjesečno za knjigovođu je mala cijena za spriječavanje glavobolje i frustracije. Kada postanete veliki preduzetnik, knjigovođa će vam svakako trebati, a i pomoći će vam u transformaciji iz MP u VP.
Dobronamjeran savjet, unajmite knjigovođu.

Ukoliko pak odlučite da sami vodite knjige u plaćate porez, poželjno je da podnesete zahtjev u poreskoj upravi za elektronski pristup aplikacijama preko kojih se podnose poreske prijave.

SP: Da ili ne?

Zavisi od mnogo čega. Ukoliko imate vrlo mali promet, mozda je ipak autorski ugovor svako toliko bolje rješenje.
Ako sa inostranim klijentima potpisujete direktan ugovor (na full-time) SP je sigurno najbolja opcija za vas.
Radite lokalno i uspjevate zadržati promet ispod 50.000 KM? SP je definitivno opcija za vas.

U regionu, Republika Srpska ima najbolje uslove za poslovanje putem samostalnog preduzetništva. 2% porez je najniža stopa u Evropi te to treba iskoristiti.

This is something we want to avoid:

serviceCollection.AddTransient(typeof(IRepository<User>), typeof(UserRepository));
serviceCollection.AddTransient(typeof(IRepository<Company>), typeof(CompanyRepository));
serviceCollection.AddTransient(typeof(IRepository<Car>), typeof(CarRepository));

If you’ve used Autofac before, something like this could be defined in a couple of lines:

public static void UseRepositories(this ContainerBuilder builder) 
{
    builder.RegisterAssemblyTypes(Assembly.GetExecutingAssembly())
        .AsClosedTypesOf(typeof(IRepository<>))
        .AsImplementedInterfaces();
}

Basically, you would get current assembly, select all types implementing IRepository<> and register them as interface they implement, which is at least IRepository<>.
After this, we’re able to inject UserRepository as IRepository<User>.

In dotnet core, you won't use Autofac most probably. We still don’t have those handy methods like AsClosedTypesOf or AsImplementedInterfaces therefore, we’d have to implement it on our own, something like this:

Assembly.GetExecutingAssembly()
    .GetTypes()
    .Where(a => a.Name.EndsWith("Repository") && !a.IsAbstract && !a.IsInterface)
    .Select(a => new { assignedType = a, serviceTypes = a.GetInterfaces().ToList() })
    .ToList()
    .ForEach(typesToRegister =>
    {
        typesToRegister.serviceTypes.ForEach(typeToRegister => services.AddScoped(typeToRegister, typesToRegister.assignedType));
    });

What does this block of code do actually?

First, we get all types from the assembly:

...
Assembly.GetExecutingAssembly()
    .GetTypes()
...

then we filter those types to the repository classes

...
.Where(a => a.Name.EndsWith("Repository") && !a.IsAbstract && !a.IsInterface)
...

and we define pairs of types with the list of interfaces they implement

...
.Select(a => new { assignedType = a, serviceTypes = a.GetInterfaces().ToList() })
    .ToList()
...

in the end, we just iterate through the pairs of types and register each of them as the interface they implement

...
.ForEach(typesToRegister =>
    {
        typesToRegister.serviceTypes.ForEach(typeToRegister => services.AddScoped(typeToRegister, typesToRegister.assignedType));
    });
...

Now we’re able to inject UserRepository as IRepository<User>, without the need for explicit registration in the DI containers of each type.

On git, every commit has author info attached to it. It is usually a name, and email. If you are working with multiple clients, it can be a legal problem if you push a code with a different email. Been there...

But even if you don't work with multiple clients, you still can work on personal side projects and company projects.  It's important to differentiate those. You might open source your project and commit history will be public to everyone. You don't want to have a company email attached to it.

It's super-easy to set this up with git config so that you never think of that again.

On the repository level, it’s easy to set it with --local parameter in the config. However, this is repetitive and you’ll forget it at some point.
What we need is a more general, and once per client set, approach, without tackling each repository individually.

1. Organize repositories on disk

Whether you’re setting git configs or not, having a directory structure like this helps with other stuff as well:

repositories
  - clientA
    + longterm_repo
    + new_proj
  - clientB
    + boring_project
    + mainenance_repo

2. Define client-specific git config files

Locate the directory where gitconfig is located. The location of this file depends on your git installation. On macOS, it’s in the /Users/youruser/.gitconfig.

Create additional config file(s) for every client, as in the snippet below.

- users
  - youruser
    .gitconfig
    .gitconfig-companyA
    .gitcontig-companyB

The content of client git config files is minimal and is shown below.

.gitconfig-clientA

[user]
        name = Dusko Bajic
        email = dusko@clientA.net

.gitconfig-clientB

[user]
        name = Dusko Bajic
        email = dusko@clientB.org

3. Edit git global config

Open .gitconfig file in edit mode and add the following blocks.

[user]
        name = Dusko Bajic
        email = dusko@mail.com

[includeIf "gitdir:~/repositories/clientA/"]
        path = .gitconfig-clientA

[includeIf "gitdir:~/repositories/clientB/"]
        path = .gitconfig-clientB

With name and email, we’ve defined the default author setup for all repositories.
[includeIf] blocks are matching the client repositories directory, with the client git config file.

And that's it. Each repository will have correct author info, per client. You can check it out by navigating to /repositories/clientA/longtermRepo and executing git config user.email. With the setup example from above, it will print dusko@clientA.net in the console.