Forem: Damnjan Jovanovic

What’s your excuse for bad code?

Damnjan Jovanovic — Tue, 28 May 2019 18:18:22 +0000

Often I hear developers trying to find an excuse for their bad code. Most of the time it end up as: lack of time, bad management, a colleague who left the company, etc.
What's the reason you heard the most?
I used to train myself to avoid excuses and take responsibility. But I also can’t resist sometimes to blame external factors 😢

How to glue a new scrum team faster

Damnjan Jovanovic — Sun, 26 May 2019 13:29:33 +0000

This is not entirely only my idea, originally it comes in collaboration with Hannes Kockro, a scrum master I had a chance to work closely in the last 2 years.

There is one variable which is true for every scrum agile team setup: “Time cannot be shrunk or stretch”. All the other things can be changed and adopted in order to make our scrum experience better or worse. If we concentrate on improving, every scrum master will give us three recommendations or guidelines based almost purely on empirical data.
This is the most common recommendations:

The team should probably consist of 5 to 9 people.
Timeframe for sprint should be one, two or maximum three weeks, while 90% of scrum teams doing it in 2 weeks interactions
The team has daily meetings, and sprint retrospective/review meetings at the end of each sprint interactions.

Ideal scenario

Idea behind is to fix timeframe, allocate people and execute a plan for one sprint period. Ideally, after one sprint period team gather and conclude that they achieved all goals. (figure 1)

figure 1

Realistic scenario

In the non-ideal world, during the sprint team has obstacles, issues, uncertainty, unpredictable behaviors of the component they do not have a control on. All of this lead to more realistic expectations of a scrum team, which allows a tolerance of +/- 20% of planned complexity (figure 2).

figure 2

Just established team

Everyone who ever tries to establish a new scrum team, or add/subtract multiple team member, faces the very same issue, the team can’t even achieve +/- 50% of accuracy. Freshly established scrum team have a lot of “unknowns”, team member do not know each other, the product itself is unknown or some team members have still very little knowledge of it.
What is initially happen is high fluctuation which goes all over from +/- 100% of accuracy for the first couple of sprints, and then it starts to stabilize around the +/- 20% belt (figure 3).

figure 3

Basically, on figure 3 we see, that team struggled first 10 sprints to understand and take in consideration their own capacity. After that period everything starts to stabilize inside +/- 20% belt (from 80% to 120% in this case).

Solution

By looking at this image it is not hard to understand that for the accurate and predictable team we need 10 sprints which length is usually 2 weeks, which gives us 2~3 months for the team to establish.
With every interaction, the team had a chance to sit together and discuss what went wrong, what they did good, propose something new and trying out. And that is the major thing which brings the team to better accuracy. With every retrospective, the team gets closer and closer to their desired accuracy.
Not every retrospective brings a golden solution, or make a “click” for everybody in the team, but every time, the team tries, with or without success. And finally, after 3 months (10 sprints) they can call themselves predictable.

But there are still variables in this equation, which we can adjust in order to get the desired outcome faster. If we saw that team need 10 sprints to establish, why not change the duration of the sprint for one week, instead of two? Figure 4 is a chart of the velocity for the same amount of time (30 weeks) like figures above, with the difference that first 10 sprints was one week framed (colored yellow), while others were 2 weeks.
With pushing the team every time into retrospectives while they still glue together, you create a room for constant improvement on a weekly basis, nobody has to wait 2 weeks to ignite some topic, a team member can try out new methods with less worry for failure.

figure 4

Conclusion

Therefore, the conclusion can be that, if you struggle to operate through big team change, or just formed a new team, give this method a try and you will see that you can speed up team glue just by repeating interactions. The new team member does not know each other well, retrospectives helping them to connect, feel each other, understands others pain.

Dead code - alive problem

Damnjan Jovanovic — Fri, 26 Apr 2019 13:49:13 +0000

How many times I saw commented part of the code, or I did comment it myself, to stay there as some kind of reminder that I have to apply action afterward. How many times I saw dead code from other developers commented or uncommented laying around and pretend it has a purpose. Well, I saw that quite enough that I already know all the answers why this particular dead code is there.

Usually, dead code is left behind because of several reasons:

Dead code as a reminder
Dead code for testing things
Dead code looking into future
Artistic dead code

Dead code reminder

This should be a reminder that we have to perform some action once when the right time comes. Some amount of work is already done, but we can’t do more refactoring at the moment to apply this change, or we don’t have time for additional code necessary to implement this change now. This is very common if the developer got an idea during working on some unrelated issue and can’t switch focus at the moment, but can leave guidelines for some future self when he has more time.

How to deal with it
If you are not the creator of this piece of software which is commented out, try to get in touch with creator and figure out does it make sense to remove it or finally implement.

Solution
Register ticket in your ticketing system which reminds you that you have to implement this change. Try to uncomment this code and put it in a separate module, or isolate as a different function. Put TODO or FIXME reminder to that code which will indicate to any developer who comes across that this pease of code, that it has to be implemented.

Conclusion: If all steps from “solution” part sound way too complicated, then it might not worth keeping it, just delete dead code.

Dead code testing things

Dead and commented code could be an “old” way how the application worked, so we just trying out a (testing) different approach with new code until we are sure which one we want to keep. In this case, dead code is A case in AB testing. I see this example, many times when the strange bug appears, or developer try out a new approach to the problem, maybe optimizing part of the code or using a different library. But still, he left the unused piece of code

How to deal with it
Hopefully, you got the data and conclusion which part of the code works better for you, so you don’t need to keep them both.

Solution
If necessary, test things once again, hopefully, you have unit tests which can prove that both solutions (commented one and uncommented) work. If you don’t have any unit test there create it, it will be the only way that you can adequately judge which code to keep.

Conclusion: There is no case when you need to keep A and B solution after you try out AB testing. Get rid of other solution as soon as possible.

Dead code looking into future

Dead code which laying there and waiting for its chance to be used. Premature optimizing, thinking way too much in advance about future requests.

How to deal with it
The code should be removed, no matter what emotional connection it has with the developer, regarding the amount of work and mental effort invested. Keeping this code in the code base is very poisoning, it introduces confusion for newcomers, and most probably this feature will never be used.

Solution
Implement thing as they are requested. It is very helpful to keep your code extendable, but predicting too much in advance which feature might be needed or change has to be implemented could be painful.

Conclusion: Follow 5 SOLID principles, and you’ll be just fine with maintaining extensions of your code.

Dead code as a state of the art

Nobody can’t tell for sure why this code is still there, but everybody avoids to do so, in respect to the effort used for writing this piece of software.

How to deal with it
Delete it and commit, then push to master.

Solution
Seriously, delete it.

Conclusion: Nobody needs someone temporary thoughts in production

Software CSI, a job of the future

Damnjan Jovanovic — Mon, 31 Dec 2018 09:53:31 +0000

This must be job position of the future, maybe it won't be called CSI SE, but it will be described like in this post. Someone has to investigate all the crime scene of dirty hacks, late-night patches, dead code, bad practices. We have enough developers in most places, but with poor enforcing good practices and no discipline, we waste their power to create beautiful structures. Instead, software developers are used for creating more of bad code.

How I come with the idea of Crime Scene Investigation Software Engineer

My mother asked me what is my daily tasks in my new workplace and what’s my job position. I could tell her that I’m a senior software developer, which is quite a dull answer already every time I change a company, but this time it felt just different.
My job was not just to jump into the code and do my work from 9 to 5. I got a job offer because of some specific skills I can bring to the company, some particular knowledge and urge for the fresh ideas they needed. The company already had software developed, but it was not in any pipeline of deployment, not tested, very fragile and maintained in a way to keep it alive. Someone has to jump there and observe where are the mistakes, what software crime has been performed, how to avoid it in future etc.
Back to my mother. She used to watch CSI Miami before (and other CSI related TV shows), and she is quite familiar with the concept, crime scene, and investigation.

My mother in the role of CSI:BERLIN

That’s how I got an idea to call my job: CSI Software Engineer. It just perfectly explains what I’m doing, I have a crime scene of bad code, and I investigate how it happened and how to prevent it in the future.

CSI SE Definition

Definition 1 (short one):
CSI SE is a scrum master but not to organize the team, then for organizing the code
Definition 2 (long one):
CSI SE, short from Crime Scene Investigation Software Engineer is a person able to identify, explore and examine the crime scene in the software. One who understands, and already experience all bad practices, anti-patterns, bad engineer behaviors, and repeatable mistakes.
CSI Engineer act like a Software forensic, he sees the crime scene of dead code, spaghetti code, fragile and dirty code and he tries to understand the reasons first, and then propose solutions.

Why we need this position

We reached a point when it is not that hard anymore to get a person for a dev job position. But to get a good one, that's very difficult. Also, so many companies struggle with development force they have, they have enough developers, well paid, working hours seems to be fair, but still, they struggle with quality.
It becomes acceptable to write bad code, write code in a rush and deploy it, make only things work, but not follow any pattern or practice.
All of this happened, because some time ago, we had such a massive deficit of engineers, so everyone got employed, no matter what skills or formal/informal education they have. Good practice or patterns wasn’t enforced, because employees were scared that they would lose developers.
So everyone who type a code, call themselves developer, even they poorly or never learn, never test, and continuing struggle to duck-tape their software, and nobody seems to see a problem there.
This is how we come to the need of CSI SE. A new job position which brings knowledge, practice, discipline, and guidelines to the already existing dev team. Crime Scene Investigation Software Engineer should be able to immediately spot all failures mentioned above and propose a solution which is acceptable for a team.

source www.rgu.ac.uk

What is a benefit for the company

The company who employes CSI SE have an advantage immediately and on the long run. Good CSI SE can immediately propose a couple of good exercises and practices to the team.
For example, if there is many places with "dead code", then CSI SE can propose that all "dead code" should be treated in a particular way (see examples here).
If the problem is unclear git messages, too unfrequent commits or inconsistent naming convention, also readily acceptable solutions and practices can be applied and be a quick win for everybody.
On the long run, CSI SE should spot weak points in dev skills, dev practices, and workflows and introduce either, learning or continuous movement, to improve. Learnings can be sessions, pair programming or training, and seminars, while by continuous movement I consider building strategies and plans where we want to go and which steps we have to implement.

Is this an executive role?

Not necessarily. CSI SE can be just like any other developer in the team, only with a specific side role. If I get back to this definition: CSI SE is a scrum master, but not to organize the team, then for organizing the code, it clearly shows that CSI SE is not a role as a team-lead or CTO. CSI SE is just part of the team with the additional task of making sure that code continually improves and removing obstacles.
CSI SE also needs to be able to transfer knowledge to other team members inside the team. Teaching others on the fly is much easier if she/he is a part of the team on the same hierarchical level.

Conclusion

I expect that is next couple of years we will have a higher demand for CSI SE, maybe industry won’t call it that way how I named it, but I guess description will be as I just described it above. Message for one who wants to jump into this wave, learn good CI/CD practices, learn TDD learn good agile and extreme programming practices, learn how to transfer your knowledge, there will be high demand for the people of the ability to apply it.

When PHP Framework Sucks Series: How not to shape your app in the shape of the framework

Damnjan Jovanovic — Wed, 26 Dec 2018 11:32:38 +0000

Intro

Below is an image I used on my presentation named "When PHP Framework Sucks" when I tried to explain what is happening when you bind too much with the framework. The image is the footprint of an apartment, with no common angles in room corners. So as you might already imagine, when you move to such apartment, you have to build your furniture custom to the shape of the angles of the room. Otherwise, you won't be able to equip your new place with standard furniture you can find on the market.

Let's make this case even worse. Let's say you move to the new city, you don't have many options to choose, and you picked up this apartment. It is empty, and you start to equip it peace by peace. After a couple of years, you decide to move to another apartment. But what you do with your already existing furniture? You have to throw it away and get a new one once you moved to the next apartment because the new one has all new room properties, this time just standard one, so your "custom" furniture does not fit anymore.

Impossible to change framework

Custom furniture is the perfect example of how developers shape their application around the framework and then they can't use it anymore in the other environment (other framework or libraries). Frameworks push you to structure your application in a specific folder structure, which is not bad by itself, but once you consider the framework change, it might be an obstacle. You might not change the whole framework as it is not what's happening very often, but sometimes just same framework, but different main versions completely make your app useless. I guess that everybody remembers migration from Zend 1 to Zend 2. I never heard of a success story, that one company accomplished that task.

Conclusion

That leaves us with the conclusion that every time a company or developer have to change a framework, she/he or company is pretty much forced to rewrite the whole application. Big refactoring or system rewriting is especially problematic with big systems which already earn a profit, and you can't just let it aside while you rewrite it in a new framework in peace. That's what I saw so many times in my career, that companies were unable to upgrade because of framework binding. They use to call that "Legacy problem" as that was something which "just happening over time" and you have zero control over it. Not many time I saw companies which enforce any DDD (Domain Driven Design) and forced the separation of their business from tools since frameworks are essentially just tools.

My discovery

I personally believe, and I already proved it, that separation from framework brings long-term financial benefit to the company. No matter what new framework version brings, or do we want to integrate our component with other framework or library, we can do that without any pain, but only if we separated our business logic from the framework. I recently had a presentation of my project which potentially can live as long as PHP lives (and not drastically change). The project is fully equipped with 100% unit test coverage + behavior tests to ensure that the list of features always works. Also, the project is so independent and abstracted from the framework, that we can appy it into another framework in a matter of one week. My company believes that this project gonna live for longer than five years, which already brings us to the point that we won't have any 'major refactoring" or "big rewriting." So if this not prove financial benefits I can't find any more obvious example.

When PHP Framework Sucks Series: Magic inside frameworks

Damnjan Jovanovic — Mon, 24 Dec 2018 14:43:36 +0000

From all of the topics, I covered at my "When PHP Framework Sucks" series, this one maybe annoys me the most. Not because I have a particular problem with style or standards for annotations and configurations than because I'm unable to reuse code and expect the same behavior with any other environment.
What I meant when I say "framework magic"? I prefer to complain about these four magic points:

Defining code inside method or class annotations
Defining classes instances in yaml or any file different than .php
All config inside yaml, XML, or any other file
Containers which "contains" anything

Defining code inside method or class annotations

We tend to use annotations so often for defining method properties. I recently saw complete documentation for swagger in controller above every action. My god, it was so long that I wasn't able to fit it in my screen height. The notation which exceeds screen hight! That's a red alarm of first grade. Long notations are not just ugly, they create so much noise, that prevents you from seeing the actual code.
It is also very common to see validation inside notation. I disagree with that so much. First, if you change the library for validation, reuse your code somewhere else, validation library becomes deprecated or similar, you will end up with the useless string above your method.
Instead, use some Value Object for validating specific data types, try to enforce strong types in every method.

/**
 *@library I‘m the useless piece of comment if you change the library hehehehe
 */
public function someMethod()
{
}

Defining classes instances in yaml or any file different than .php

Classes instances in non-PHP files are very problematic if you want to follow the execution line in your IDE and then you end up that some class is a dead end. This class is not a dead end as it seems to be, there is a code which instantiates it, but it is in yaml.
Wait, YAML ???
True, many time I see the declaration for classes which we have to define as a "service" for example, inside XML or yaml files.

All config inside yaml, XML, or any other file

Generally, config inside yaml files annoys me. I know it brings some readability for folks, but I always wonder, why not simply in php? No need to parse, no need to warm up.

Containers which "contains" anything

This one is wrong, at least from two perspectives. Perspective number one, the container return type is what? Containers can return on get method call (or similar name) any type, any object, or property. How do I know that in the name of God? How can I call any method on that object since I don't know its type?

public function testAction()
{
    $something = $this->container->get('hehehehe_you_newer_know_who_I_am');
}

The second problem is that container violates such a hard "Interface segregation principle" the famous "I" in SOLID principles. Your Controller or any other class which has access to the container knows too many things at this point.

Conclusion

Notations are comments, you can use it to specify some method properties, but do it with caution. If you try to find the usage of the class, defined in yaml, good luck! There is unnecessary parsing of yaml and XML configs. Controllers and other container aware objects know too much, but you don't have an idea what container returns.

When PHP Framework Sucks Series: Framework topic on a job interview

Damnjan Jovanovic — Thu, 20 Dec 2018 14:46:51 +0000

If you're PHP developer of any experience and you were at least at one job interview, then you've been asked to describe your knowledge in a specific framework. This question becomes so common that we considered it standard for job interviews for PHP positions. Why companies and recruiters insist so much on knowing how you're skilled in the specific framework? Why might you not pass the interview round if your experience in the specific framework is not sufficient?

A framework is a tool, not a skill

Everybody should consider framework as a tool, but never as a skill. Separating programming skills from knowledge of a specific framework is particularly important during the recruitment process. Many good candidates were rejected since they do not have experience into a specific framework. That could mean two things:

Companies bind themselves to framework too much
A person who is doing the recruitment process has no or little knowledge of other frameworks.

I already covered the first topic and dedicate whole blog post. For the second one, there is no simple solution except educating people to understand the framework purpose better.

Tools

Tools are the framework, libraries, IDE, computer, version control systems, virtualization software, etc. Tools are something we use to build a product. We can build our product with the various combination of tools. In most of the cases, tooling does not determinate is something is possible or not. Companies sometimes bind themselves way too much to the framework, to the level that they need skilled people who can only think inside the framework playground.

Skills

Skills are clean code, documentation, solving problems, testing strategies, architectural skills, etc. Skills are something developer may have or don't. Well skilled developer, or the one eager to learn, absolutely can handle any tool (framework in this case) and build a good product.

Conclusion

Tools are a screwdriver, power drill, and spirit level.

Skill is to use these tools to create something.

Common question

I already got this question a couple of time, here and at my presentations, so I will answer it here shortly.
If a company have [Symfony|Zend|Laraver] application, then they need [Symfony|Zend|Laraver] developer, right?
If your business is for example "music streaming service", and your application is "Laravel" application then that's so wrong. Your application must be "music streaming application", not "Laravel" application at any cost!
The reasons why is:

If you unbind from your framework, then you can upgrade without fear, to the next version.
You'll be able to reuse your code in/with other environments, libraries, and frameworks.
You don't have to adapt your app every time framework deprecates some of their libraries.

Once again, a framework is a tool, not a skill.

Here are the other resources from this series directly connected to this one

When PHP Framework Sucks Series: How not to shape your app in the shape of the framework

Damnjan Jovanovic ・ Dec 26 '18

#php #webdev #career #productivity

When PHP Framework Sucks Series: Business logic free Controllers

Damnjan Jovanovic ・ Dec 18 '18

#php #webdev #showdev #testing

When PHP Framework Sucks Series: Business logic free Controllers

Damnjan Jovanovic — Tue, 18 Dec 2018 07:38:17 +0000

Business logic in controller

Let’s start with Controllers and your business logic. Rule number one: Do not put business logic in controllers at any cost! Business logic in controller is particularly problematic because controllers usually derive from the framework. Also, when they extend the framework base controller class, they usually know too much (containers). As the name implies, business logic is your code which you want to reuse and make independent of libraries and frameworks. It should be well separated and encapsulated since you might probably call the same method from different places.

Here is the example of Symfony controller best practice page:

namespace App\Controller;

use App\Entity\Post;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\Routing\Annotation\Route;

class DefaultController extends AbstractController
{
    /**
     * @Route("/", name="homepage")
     */
    public function index()
    {
        $posts = $this->getDoctrine()
            ->getRepository(Post::class)
            ->findLatest();

        return $this->render('default/index.html.twig', [
            'posts' => $posts,
        ]);
    }
}

Here, business logic sits in an inappropriate place. Instead, we should have a class which returns us the latest posts. We can call that class for the sake of simplicity PostsFromDatabase.

namespace ExampleNamespace;

class PostsFromDatabase
{
    /** @var ManagerRegistry**/
    private $doctrine;

    public function getDoctrine()
    {
        return $this->doctrine;
    }

    public function __construct(ManagerRegistry $doctrine)
    {
        $this->doctrine = $doctrine;
    }

    public function getLatest()
    {
        $posts = $this->getDoctrine()
            ->getRepository(Post::class)
            ->findLatest();

        return $posts;

    }

}

Test for this class, in this case, is straightforward

namespace ExampleNamespace;

use Doctrine\Common\Persistence\ManagerRegistry;
use Doctrine\ORM\EntityRepository;

class PostsFromDatabaseTest extends \PHPUnit_Framework_TestCase
{
    /**
     * @covers \ExampleNamespace\PostsFromDatabase
     */
    public function testGetLatestShouldReturnSameCollectionAsFindLatestReturns()
    {
        $managerRegistryMock = $this->createMock(ManagerRegistry::class);
        $repository = $this->createMock(EntityManagerInterface::class);

        $managerRegistryMock
            ->expects($this->once())
            ->method('getRepository')
            ->with(Post::class)
            ->willReturn($repository);
        $repository
            ->expects($this->once())
            ->method('findLatest')
            ->willReturn(['post1', 'post2']);

        $postsFromDatabase = new PostsFromDatabase($managerRegistryMock);
        $latestPosts = $postsFromDatabase->getLatest();

        $this->assertEquals(['post1', 'post2'], $latestPosts);
    }
}

Now our controller looks like this

namespace App\Controller;

use ExampleNamespace\PostsFromDatabase
use App\Entity\Post;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\Routing\Annotation\Route;

class DefaultController extends AbstractController
{
    /** @var PostsFromDatabase **/
    private $postsFromDatabase;

    public function getPostsFromDatabase(): PostsFromDatabase
    {
        if (null === $this->postsFromDatabase) {
            $this->postsFromDatabase = new PostsFromDatabase($this->getDoctrine());
        }

        return $this->postsFromDatabase;
    }

    public function setPostsFromDatabase(PostsFromDatabase $postsFromDatabase)
    {
        $this->postsFromDatabase = $postsFromDatabase;
    }

    /**
     * @Route("/", name="homepage")
     */
    public function index()
    {
        $posts = $this->getPostsFromDatabase()->getLatest();

        return $this->render('default/index.html.twig', [
            'posts' => $posts,
        ]);
    }
}

The controller is free of business logic and now only deal with routing, rendering and know which service to call. But there is one more benefit you might not spot so far:

Half of our code, now have a unit tests 🤩🤩🤩🤩🤩🤩

And you should not stop there, now controller is super easy to test (that's why I left 'set' and 'get' methods for PostsFromDatabase), but that I will cover in the next chapter of this series.

Stay here for a second. Did you ever saw that framework tutorials in their examples, implies you should test your code? Most modern frameworks have a "placeholder" for tests. But I don't remember that I saw one framework which has implemented unit test measure, tests required, or tests in their tutorial examples. I'll leave this question here for some future blog posts.

When PHP Framework Sucks Series: PHP Frameworks overview

Damnjan Jovanovic — Mon, 17 Dec 2018 12:42:02 +0000

INTRO

If you are working as a PHP software developer, there is an extremely high chance that all of your application, you’re currently working on, using frameworks of any kind.
PHP community developers of all levels worship frameworks since there are big historical and practical reasons for that.

Historical reasons

Since early PHP versions, developers were disreputable because not everybody considered PHP as a programming language, similar like JavaScript couple of years ago. While strong type language existed decades ago, PHP continues to be soft type since now, only in version 7 basic types were introduced. There is also a matter of the fact that you can script in PHP without using a single object.
But that opened a space for frameworks to step in and introduce themselves as a tool or standard which will shape projects, give them right and order, introduce structure and rules.
And finally, they did. Frameworks are good examples of nice structures, using all available new features PHP offers with every version, enforcing some good practice, etc.

Practical reasons

The framework offers a lot of common problems already solved. They offer a nice ecosystem for other developers to contribute and plug their components. There is a lot of online resources for learning and stay updated about any particular framework. Also, what every framework community tries very hard, is to make setup and usage easy.

WHEN PHP FRAMEWORKS SUCKS

I recently had the opportunity to give a talk on a conference and one meetup about why PHP framework sometimes sucks. Sometimes things we see in framework tutorials does not seem to be very much aligned with some object-oriented standards we are striving to enforce, and with basic clean code guidelines. On the other hand, there is nothing wrong with using a framework, if you use it right.

This article is first "pilot" article in this series, to measure how much audience on dev.to are happy to learn about this subject in blog-series format. In every new blog in this series, we will go more in-depth about every specific topic I covered during my presentation.
I'm very excited to share this knowledge, as I saw many developers suffer from bonded-to-framework disease.
// Detect dark theme var iframe = document.getElementById('tweet-1058306144458956800-280'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1058306144458956800&theme=dark" }
I won’t spend much time here on any particular framework discussion. This series will be just a guide how to unbind yourself from frameworks and use them as a tool, instead of being independent.
Here is the link to the presentation slides.

Stop using "It blocking me" excuse

Damnjan Jovanovic — Thu, 13 Dec 2018 15:27:44 +0000

You now think it is impossible, it is not realistic, but let me take 10 minutes of your time to read this and think. You might change your mind.

You get it right, nothing block you to make progress, even if you are 100% sure that you don't have any impact, there are still things you can do, and not blame any external factor. I have a chance to form a small, agile team, consist of briliant and open-minded people. One of the first statements we agreed on was “We won’t let any external factor prevents us from achieving goals”. Another statement we want to achieve is “We never blame any internal or external factor for our unsuccess”.

There is five stage of “it blocks me” mantra, and I will show it one by one in detail and try to explain it with an example. I believe that everybody went through these mantras during professional career, most people get stuck on 3rd one, and they need just a little push, to jump into more desirable 4th or even better 5th.

Blame - It is all faults of others
Blame realistically - I could do something but it is pointless since other things are not ready
Blame with action - I did my part, but it failed because of others
Do your job - I did what I could, to make it works.
Master your job (No blame) - I did all I can do to finish my work independently of external factors

Blame 👎

Also known as: It is all faults of others
Manifest: Person who use it find it useful for escaping any responsibility, from work to the private life. She/he finds all the reasons for failing in other factors, such as politicians, boss, weather, etc. Blame person is never satisfied, always failing, but uses “It is all faults of others” mantra to make herself/himself happy and calm.
In team: This is the type of person in the team who never take any responsibility for any tasks, also do not participate in decisions because believes that individual can’t change anything. If you have a person like that in your surrounding or team, help them to understand that they always have an impact on the outcome.

Blame realistically 🤞

Also known as: I could do something, but it is pointless since other things are not ready
Manifest: This type of persons believe they do have a limited impact on external factors, and that prevents them from acting. But unlike typical blame person, they understand that they could do something, their part of the task, but still, the outcome won’t change since external factor may fail.
In team: In a team, you can spot realistic blamer as a person who is usually pessimistic, always take tasks only if all external factors are positive. Example of that could be frontend developer, who wants to start her/his work, only if backend part is done and visible. This type of person in a team does not perform any action until make sure that all component she/he depends on is in place.

Blame with action 🤙

Also known as: I did my part, but it failed because of others
Manifest: Person who do all tasks required to be done, not more not less. Blamer with action pays all his taxes, do all the tasks he found in Jira, he might not agree with all of them, but they “did their part”. Off course if anything fails, and if the external factor is involved, they would blame it with appetite, especially because their tasks are fulfilled.
In team: This type of personality is the most common in teams, they are usually reliable, hard workers, oriented to their own goals, and their own tasks. They measure the success of the sprint by their own tasks accomplished rather than team goal being achieved. Teams rely on them when it comes to the estimation and execution of their own tasks, but the team knows that this personality type won’t do anything to eliminate external factor impact. Even worst, she/he do not care about things outside of her/his scope.

Do your job 👌

Also known as: I did what I could, to make things works.
Manifest: This type of person, do everything her/his task requires if necessary creates a mock for an external factor if possible, but still blame external factor if there is an overall fail. “Do your job” person does not feel comfortable to take big responsibilities, he wants to do as much as he can even outside of his task scope, but still be happy only to present part he accomplishes as a success, and external fail as responsibly for overall fail.
In team: This is the person who takes all action to make goal achieved, she/he performs many additional tasks to ensure that their main task (goal) can be achieved, but if there is an external component which they couldn’t have an impact on, they will point that out clearly.

Master your job (No blame) 🤟

Also known as: I did all I can do to finish my work independently of external factors
Manifest: Person who takes critics, and personal fails as learnings. When you give them a feedback, they do not try to explain to you that you’re not right, or they won’t explain to you what you meant with your own feedback for them. They take it as a lesson to be learned. Especially negative feedback helps them to understand that something went wrong, and they can change it. This is the type of person who takes full responsibility, don’t judge others or external factor, she/he always try to do all they can to achieve a goal.
In team: No blamer do their job and make sure that they create an environment when they do not depend on some external factors. They define their scope and their goal to be possible without introducing too many external dependencies. They create a mock for everything they can. They do all in their power to make goal achieved. But if the goal is not achieved, they took full responsibility for it.

Conclusion

I’m particularly proud of my team that we want to go toward 5th step of taking responsibility. That already help us so much, we are so accurate, realistic and goal oriented during our sprint planning than I experienced ever before. Every team, every person could be in any of these 5 stages, our task is to recognize that, take responsibility and try to move toward the next upper stage.

It blocking me - is just an excuse

p.s. earthquakes, disaster, war, and similar events do not count as obstacles you can have any impact on, so they do not apply to this article.

The 2018 year of ladies come back in tech

Damnjan Jovanovic — Sun, 09 Dec 2018 17:22:15 +0000

There are zero obstacles for a female to do computer programming but yet we still struggle with Female/Male ratio in IT companies.

A deficit of women in tech is being a topic for a while. Everybody knows the fact that there were many women in Computer Science since it’s beginnings. But so suddenly Female/Male ratio drops to the level when it becomes a predominantly male job. I recently heard from one of twitter account I follow that people are still very shocked when they realize she doing programming. And she lives in Europe, which we can consider as very open when it comes to breaking gender-profession stereotypes.

The stereotypes which block Women to enter a tech

History

I heard a theory that the IT industry is male predominant, because of PC advertisements in the 80s and 90s. They suggest that advertisements always put personal computers in the boy's room, as a gaming device. I still remember that stereotype that computer is only for fun (game) when you’re young, but as you get older you start using it seriously (for work/study/research). This stereotype breaks very quickly, in the 90s and 2000's parents discovered the importance of computers in our life, and they definitely understood that you have to make the computer more accessible to your kids. But even that didn’t break the stereotype of computer programming being a male job.

Evidence

Of course, this stereotype is nothing more than just stupid prejudice, there are zero obstacles for a female to do computer programming. There is no biological or any other physical border for any gender to perform any IT job, the same applies to race, sexual orientation and other stereotypes which poisoning our world and our industry. On the other hand, there is no clear evidence that any gender can perform any computer related tasks better just because of gender predispositions. So question still remains, why we do not have more females in the IT industry? I don’t know the answer, but I see that things changing, and it particularly changed this year.

What’s different this year

Let's start with general things which I was able to observe. There is a great number of female in IT in recent years and I see them joining forces, encouraging themselves, grouping and help others to overcome obstacles of stereotypes.

Social network and events

On the social network, you can spot many females-in-tech related groups, like Women Techmakers Berlin. That definitely encouraged and helped other women to join tech. I also saw a lot of supportive individuals there, which are eager to help, contribute use their connections and free time to help newcomers faster onboard into IT world. There are meetups organized and handled usually by social network groups, where women in tech can actually interact in the real world, have face to face conversations and networking.
// Detect dark theme var iframe = document.getElementById('tweet-1022179002751102976-452'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1022179002751102976&theme=dark" }
It is obvious that there is a bigger number of social network groups of that kind, like never before. They are very active and dynamic, and I can only conclude based on my observation that this group definitely doing a good job by increasing F/M ratio in tech.

Books

I do not remember that there were two publications in one year which had so much impact on me like Dominica DeGrandis book “Making Work Visible”, and Nicole Forsgren publication “Accelerate”. Making work visible, talks about things you already know, things which bother you, but so far nobody puts it in some order, structure it and give it a name, as Dominica did. On the other hand, Accelerate talk mostly about things we trying to convince others, but they do not believe. Accelerate give numbers, pure numbers from scientific researches, so there is no anymore question of opinion, do you prefer one method or other, there are numbers which do not lie.

Conferences

As you might notice the ratio of female speakers in conferences grows. And it’s not just awesome because we have gender diversity, we are also exposed now to a diversity of subjects. Whole new subjects are now on tech conferences, not just related to programming skills, but also soft skills. Just to mention two speakers with non strictly technical talks, which I come across recently Emily Freeman, Svetlana Sharipova.
// Detect dark theme var iframe = document.getElementById('tweet-1061619911947096066-25'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1061619911947096066&theme=dark" }

DEV.TO

I found this great article written with the first-hand experience of building women-in-tech related community

How Building a Women Who Code Chapter Made Me a Better Engineer

Helen ・ Sep 22 '18

#womenintech #community #management #learning

Or this one about women as programmers stereotypes

Article No Longer Available

How to survive your own startup crash

Damnjan Jovanovic — Tue, 04 Dec 2018 20:54:21 +0000

This is a very personalized story, and it is based on my first startup failure. Even it is very specific and some or most of the circumstances does not apply to you or your startup, I’m sure you will come up smarter than me at the time, after reading this, because at least, I hope you won’t repeat my mistakes.

Introduction to my Startup

I was a Co-Founder at startup for energy trading http://balanciq.com. We tried to build a software for big energy trading companies which can possibly save them some time and reduce errors by automating their manual data entries. But as you continue to read you’ll find out that it failed, and here are the main links in the chain of events and circumstances which caused a crash.

Your environment narrows you

I was not lucky enough to get startup idea while I grew up in some of the famous startup cities like Berlin, Dublin or NY. Instead, I grew up in eastern Europe in the territory known as Balkans. If this geographic name does not mean anything to you anything, don’t worry, I’ll try to explain in short which obstacles I had there. At Balkans, most people are not used to the concept of paying for digital goods, that’s why you can’t come up there with an idea such as Spotify, Netflix, etc. Simply this sort of ideas would never come across your mind because you’re not exposed to the concept. That was exactly the problem I had, I started to develop my platform, with features and specifications I found out at my surrounding. I was briefly aware of broad regulations in Europe but for example, North America, Asia, and other possible markets were huge unknown to me.
That’s why it is very important to go out and see how things work outside of the borders of your world. That’s the only way you can come up with a solution for some problem people in distant places have.

Sit and read first

I don’t like to do everything “by book” and generally I believe that we should experiment. But what happened to me was completely avoidable, because I wasn’t the first one. There are people who already experienced failure and explained that in their publications, such as The Lean Startup from Eric Reis

What I did wrong? First, I built a product, then asked a customer what they need. That was so terribly wrong, that it cost me so much time spent on developing something nobody gonna uses. Off course you can’t really have a startup with a sketch of your idea on a piece of paper for years and start to build once you get a critical mass of customers, but you definitely have to build your product with your customer.

Find your first customer ASAP

No matter what it costs, try to engage some customer immediately during development and ask them for feedback as often as possible. Also, offer them a product for free. We started nicely with customer acquisition. We had a couple of companies on our side, and we had frequent feedback from them, but then we started to travel here and there, pitch our business idea, and that moves us away from our actual clients. That’s sad :(

Quit your job if you can

There is no success if you’re not engaged 100%. If someone tells you opposite, don’t believe. You need to put all your effort and strength on your startup if you want to test it fast. Otherwise, it could take much longer, and if fail you lose much more time and energy if you had your regular job in parallel. I made exactly that mistake, I took some freelance projects on the side, which just postponed my progress.

Nobody gonna stole your idea

This is fear present at most of the startups. But don’t worry, does not matter how good your idea is, if you already work on it, feel free to share it with others. Paranoia does not help but sharing might helps because of your friend, business contacts or family will give you their opinion or idea which may impact way how you will develop your product. I personally kept my idea for some time in secret, but only when I uncovered it to my family and friends, I started to get some cool advice and got some great contacts which helped me at the time.

Failing startup is a great opportunity for starting a new one

I really don’t need to explain this one. If you already tried startup idea, there is a high chance that you will try another one soon, because you simply enjoy that.