Tomasz Dziurko

Świąteczna opowieść. Polska branża IT w 2023

Sat, 23 Dec 2023 12:01:35 +0000

Tuż przed Świętami 2023, w ramach łapania oddechu pojawiłem się jako gość w podcaście Osobowości IT prowadzonym przez Agę Myśliwczyk, gdzie razem z Grażyną Dadej próbowaliśmy podsumować ultraciekawy w IT rok 2023, trochę wróżyliśmy co nas czeka w 2024. Poza tym rozmawialiśmy o byciu dobrym liderem, przywództwie i ścieżkach kariery, które nas doprowadziły do miejsc, w których jesteśmy i jaką z tego można czerpać naukę.

Czy warto się specjalizować - mini wywiad w Brand w IT

Wed, 31 Aug 2022 12:00:00 +0000

W sierpniu Aleksandra Rajkowska, znajoma z branży IT poprosiła mnie o wypowiedź na temat blasków i cieni specjalizowania się w naszym zawodzie.

Pierwsze kilka akapitów poniżej, a całość (w tym wypowiedzi Krzysztofa Kempińskiego i Oli Kunysz można przeczytać na stronie Brand w IT).

Czy warto się specjalizować? Co byś doradził tym, którzy mają ten dylemat?

To zależy od wielu czynników, ale przede wszystkim od etapu kariery w naszej branży. Na samym początku skoncentrowałbym się na tym co nas najbardziej kręci w tej ścieżce kariery: czy frontend czy backend czy może devops. Na miejscu zaczynających w IT wybrałbym sobie taką dziedzinę, język oraz 2-3 technologie towarzyszące. A następnie właśnie na te rzeczy położyłbym główny nacisk nauki.

Dlaczego akurat tak? Większość firm szukająca juniorów koncentruje się na jakiejś specjalizacji, np. Junior Java Developer, Junior DevOps Engineer czy Junior Frontend Developer. Na takie ogłoszenie spływa do firmy kilkadziesiąt, a czasem kilkaset CV. Żeby się wybić, trzeba w tym CV mieć coś wyróżniającego się; coś, co sprawi, że przeglądający je zobaczy, że może i jest to osoba na początku swojej drogi w IT, ale przynajmniej wie już jaka to droga.

Po drugie, im więcej będzie pasji w tym wyborze, tym łatwiej będzie przychodziła nauka, pisanie własnych projektów, poznawanie narzędzi i ogólnie pojęty rozwój. Jeśli nie odczuwasz satysfakcji po spędzeniu kilku godzin dziennie na pisaniu kodu, oglądaniu kursów, czytaniu dokumentacji, będzie Ci bardzo trudno zmotywować się do regularnej nauki, a tylko takie podejście może przynieść widoczne efekty i sukces w postaci zdobycia pierwszej czy drugiej pracy.

Pełny wywiad jest dostępny tutaj.

Nigdy nie mieliśmy biura. Case study SoftwareMill - artykuł i temat numeru w czasopiśmie HR Business Partner

Mon, 13 Jun 2022 12:00:00 +0000

W majowo-czerwcowym wydaniu czasopisma HR Business Partner jako temat numeru ukazał się mój artykuł “Nigdy nie mieliśmy biura. Case study SoftwareMill”, w którym opisuję nasze (SoftwareMill) podejście do budowania kultury organizacyjnej, zaangażowania oraz efektywności w ponad 80-osobowej firmie zdalnej.

Pierwsze kilka akapitów poniżej, a całość można przeczytać albo w wersji papierowej numeru albo na stronie czasopisma.

Zaprogramowaliśmy się w SoftwareMill na 100-procentową pracę zdalną od dnia zero. Obecnie jesteśmy ponad 80-osobową organizacją, w której osoby z firmy znają się lepiej nawzajem, niż kiedy pracowały stacjonarnie w biurze. Oto, co u nas działa i pozwala budować przywiązanie do firmy na tak trudnym rynku pracownika, jakim jest branża IT.

Od zawsze jesteśmy w pełni zdalni, działamy w modelu, który inni odkryli ponad 10 lat później. Tworzymy projekty IT dla całego świata, każdy z nas z własnego domu czy co-worku. Nigdy nie mieliśmy i nie planujemy mieć biura. A wszystko zaczęło się w 2009 r., gdy właściciele zachęceni wcześniejszymi doświadczeniami pracy zdalnej dla RedHata stworzyli SoftwareMill. Od tego czasu wypróbowaliśmy wiele sposobów na budowanie kultury w firmie, tak by zdalność nie przeszkadzała, a była wyróżnikiem i wspierała budowanie silnego zespołu. Wdrożyliśmy procesy i zasady, które pomagają nam pielęgnować relacje w zespole rozproszonym, a jednocześnie pozwalają korzystać z elastyczności, jaką daje telepraca. Wyróżniamy się na rynku pracodawców IT jako organizacja, która po prostu „umie w pracę zdalną”.

Organizacja pracy w 80-osobowej zdalnej firmie

W pełni zdalny model pracy to jedna z cech charakterystycznych SoftwareMill. W DNA organizacji mamy zapisane jeszcze zarówno płaską strukturę, która z czasem wyewoluowała w model wzorowany na holakracji, jak i pełną transparentność, także finansową. Te czynniki sprawiają, że w zakresie zarządzania zespołem i całą firmą różnimy się od klasycznych organizacji i konkurencji. By pokazać pełen kontekst, przedstawię odrobinę historii.

Od turkusu po (r)ewolucję

Gdy SoftwareMill miał około 25 osób – Zarząd, który ciągle chciał programować i brać udział w projektach, zdecydował się przejść na bardzo wtedy rewolucyjny model firmy, dziś nazywany „turkusowym”, z tzw. płaską strukturą.

Główne założenie było takie, by wszystkie decyzje podejmować jak najbliżej źródła problemu. Dzięki wprowadzeniu pełnej transparentności (w tym także wynagrodzeń oraz stawek dla klientów) zespoły projektowe mogły podejmować samodzielne decyzje na podstawie pełnego obrazu sytuacji. Do większych inicjatyw stworzyliśmy Grupy Robocze i opracowaliśmy zasady demokratycznych głosowań całej firmy nad wypracowaną w Grupie propozycją. Taki model zarządzania sprawdzał się u nas przez dobrych kilka lat.

Ciąg dalszy tutaj.

Holacracy in a software house

Thu, 29 Jul 2021 12:00:00 +0000

Part 2 of the interview with Tomek Dziurko, SoftwareMill’s VP of Engineering

Part 1 is available here

Kamila Stępniowska talks to Tomek Dziurko about how decisions are made at SoftwareMill, how guilds work, and why the company opted for their own version of holacracy.

Kamila Stępniowska (KS): The closer I got to know SoftwareMill, the more it began to remind me of Spotify in terms of its culture of organization. From what I know, that’s not where your inspiration came from, but Netflix is a kind of newly-discovered source of inspiration. You discussed Reed Hastings’ “No Rules Rules: Netflix and the Culture of Reinvention” at your reading club’s meetings. Are you thinking of implementing any of the organizational solutions presented in the book?

Tomasz Dziurko (TD): We’re planning to. What we really liked was the emphasis on feedback culture – very honest, regular feedback, focused on what can be done better. The book broadly describes a fairly developed system for giving feedback so that it’s constructive and not taken as a personal attack. At SoftwareMill, we work in a similar manner, however, we feel we can still improve in this area. We are aware that giving and receiving feedback is generally a tough nut to crack. I assume that little by little, we will get to where Netflix is: providing feedback as often as possible. Feedback that’s timely, delivered following a given situation is a lot more effective because both sides still remember all of it and it’s easier to communicate.

KS: It seems that SoftwareMill is open to internal discussion. You don’t have departments but so-called guilds. I take there’s more to that than just a different name?

TD: SoftwareMill used to be a flat company, so everyone could express themselves in any area. Whenever a decision had to be made, we asked for everyone’s opinion, and we made decisions together by a company-wide vote. And it was great, it worked well until we grew to about 40 people. It then turned out that not all decisions can be made together. Some people simply don’t have the knowledge or context to consciously vote for or against something. That’s when we decided that we need to narrow the groups down a little in terms of competences – to people who really want to contribute in a certain area, are interested in what’s going on, and are somewhat familiar with a given part of the company’s activity. We introduced a holacracy, or at least that was our starting point.

At SoftwareMill, as you mentioned, we have guilds – every area of the company’s activity has its own guild. It also has a guild master who coordinates activities and makes sure that the things that need to happen actually happen. At the moment, many smaller decisions concerning a specific area of activity of the company are made within the guilds. The decisions are made by people who really have the knowledge and context, and who know what the risks, consequences, business goals, and reasons for the course of action are. It’s important to note that anyone can belong to a guild – you simply need to express interest and consciously decide that “OK, I’m interested in this area of the company’s activity, so I want to do this, I want to and have the time to keep track of this.” We haven’t completely got rid of our flat structure. Decisions that impact the entire company are still made via voting by every member of the company. Here, we stick to the values SoftwareMill grew out of – everyone can add do their own bit and shape the company.

Full article can be read at SoftwareMill’s Blog here.

VP of Engineering working in HR?

Wed, 21 Jul 2021 12:00:00 +0000

Can VP of Engineering handle recruitment processes too?

First part of an interview with Tomek Dziurko, SoftwareMill’s VP of Engineering

Part 2 is available here

Kamila Stępniowska (KS): Tomek, your title on your LinkedIn profile is VP of Engineering, but you also scout for new talents and watch over the recruitment process, so what’s going on here? ;)

Tomek Dziurko (TD): Yes, that’s right. Choosing the right people to join SoftwareMill is one of my most important responsibilities. The IT market is very demanding, especially when it comes to experienced specialists, so the help of a programmer with 13 years of experience can only help, both when it comes to finding the right people and to convincing them that SoftwareMill is a good place for them to develop further.

Luckily that’s not the only thing I work on, although I admit that it’s quite important.

KS: What else does your job involve?

TD: In product companies that build an app, the role of the VP of Engineering is much more closely tied to technical aspects. Such a person really supports the technological direction, working together with the CTO on selecting tools, languages, architecture – that is elements with strategic importance for the product’s development, and so for the existence of the whole company. Since most programmers work on developing the same application, the VP of Engineering also focuses on improving communication and collaboration between teams. All this increases the chances of the app’s success and the financial success of the company. After all, at the end of the day, it’s the most mundane mission of each company: to make money that can then be spent on pay rises or a new Ferrari for the CEO. Exactly in that order, of course :)

In the case of a software house, my role is a little different, although of course our CEO probably wouldn’t mind having a Ferrari either :) My main task, other than coordinating the recruitment process for different technical positions, is supporting teams in effective work, by which I mean: supporting the development of technical knowledge, creating paths for development in different technical positions together with senior developers and architects, and taking care of the development of soft skills in the team as well as supporting the exchange of experiences and know-how between teams.

KS: What does that mean in practice? How do you encourage the exchange of knowledge at SoftwareMill?

TD: When it comes to learning, I either organize or help to get different groups of knowledge exchange going within the company. We make sure that people who want to learn or – what’s even more valuable – share their experiences have plenty of opportunities to do so here. We currently have two groups preparing for certifications (AWS and Apache Kafka), a Technical Reading Club (currently discussing “Design It” and previously went over “Designing Data-Intensive Applications” by Martin Kleppmann), and a Soft Skills Reading Club, where we read more about the human aspect of leading teams and companies. We started by going over the classic “Peopleware: Productive Projects and Teams”, and then we read “No Rules Rules: Netflix and the Culture of Reinvention.”

Full article can be read at SoftwareMill’s Blog here.

O wspieraniu rozwoju i integracji programistów w czasach koronawirusa - 4Developers 2021

Thu, 27 May 2021 12:00:00 +0000

Moje wystąpienie na konferencji 4Developers 2021 na temat jak to robimy, że jesteśmy zgraną drużyną pracując w 100% zdalnie? Jakie aktywności i rozwiązania wypracowaliśmy przez prawie 10 lat pracy zdalnej, które mogą wam, waszym zespołom czy nawet firmom, pomóc w czasach pracy zdalnej zadbać zarówno o integrację ludzi jak i wspieranie ich rozwoju.

Lobotomy to your object-oriented thinking - "Elegant Objects, volume 1" book review

Wed, 26 Jul 2017 00:00:00 +0000

Step one in the transformation of a successful procedural developer into a successful object developer is a lobotomy.

– David West

This is the first sentence in “Elegant Objects, volume 1” book by Yegor Bugayenko and after reading it from cover to cover I could not agree more. This book will not leave you neutral, you will either strongly agree or disagree with claims stated there, but it is definitely worth your time. It will challenge what you know about programming, it will challenge what you think a proper object-oriented design is and it will challenge many old, well-established so called “good practices” you have seen during your career. Fasten your belts, move your coffee mug away from your keyboard and keep reading.

Image from http://simpsons.wikia.com

Content

“Elegant Objects, vol. 1” in over 200 pages gives you 23 practical tips for developers to write more object-oriented, thus more maintainable code. The author uses very interesting allegory by treating every object as a human being and splitting these suggestions into a four anthropomorphized chapters: birth, school, employment, and retirement.

The Birth chapter is rather short and covers object creation, starting from naming strategies through suggestions how to keep constructors clean and easy to test. Education and Employment are the core of the book and contain paragraphs describing how to build encapsulated, immutable and easy to test objects, how to use interfaces with stub implementations to simplify testing without mocking hell. Then we could read some rants about “encapsulation by getters/setters”, sections about the clear distinction between data structures known from procedural languages and well-defined classes and objects from OO programming. Last paragraph Retirement is about avoiding nulls, using only checked (yes, yes, no typo here :) ) exceptions and recovering from errors.

Each suggestion is clearly described with code snippets showing bad, and then, proper approaches to solve the discussed topic. There are also links to discussions on author’s blog so you could read what other have to say about each suggestion. Most paragraphs are short so the reader could split reading sessions into smaller ones without the need to re-read several pages. Paragraphs are also rather autonomous so you could read them in any order, even if there is a reference to something covered elsewhere, it will be a direct reference to paragraph number where the reader should look for mentioned information. Everything seemed to be stable – there were Team A and Team B and they were the best places to improve players’ skills. Teams C and D paid super high salaries and bonuses for goals, but at the same time they used old approaches far away from modern football. Knowing this, every good player could discuss the future with his agent to decide what is the best for him at a given point of his career as a professional footballer.

My Notes

During the reading, I put many sticky notes with sentences worth remembering, below the most important or intriguing ones.

Avoid names ending with “-er”, it suggests that such object is only a collection of procedures that manipulate data and not a fully-independent entity that is capable of acting on its own
Each class should have only one primary constructor with initialization logic there, non-primary (secondary) constructors should only prepare data (params conversion, etc.) and call a primary one.
Each class should have maximum four properties. Author makes an analogy to coordinates in the universe (x, y, z and time)
Instantiation should be strictly separated from execution, new operator is allowed only inside secondary constructors
Every public method must be a part of some interface. Why? See note below.
Avoid mocking hell by using no mocks, provide default (fake) implementations of all interfaces that could be later used in your tests. This way other developers won’t have to setup everything in each test, they could simply use fake implementations that need to be written once.
Avoid mutable state.

Mutable objects are an abuse of the entire object-oriented paradigm.

Avoid temporary coupling between lines: with immutable objects you do not have two separate phases of object instantiation and object initialization (first “new”, then multiple setters) so we can not accidentally put any logic before the object is fully ready to use. The immutable object is either non-existing or fully initialized entity ready to work for you, so reordering lines won’t have any effect on application logic, the same immutable object will be used.
Show your respect to others by writing code that assumes they are junior programmers. Not by showing off and demonstrating your skills but by writing simple and easy to follow code.
Favor small objects with the well-defined scope and responsibility -> max four public/protected methods. If this number goes above five, think carefully as probably this class has more than one responsibility.

Static methods are like a cancer to your objects.

You can’t trust objects returning null, every time at some point you will have to check for nullability.

As you can see some of them are only a bit more strict rules that we used to apply during our daily job, but some are quite radical. If you want to understand them better or read if readers agree or disagree with presented approach you could use a link to the discussion on Yegor’s blog (e.g. Don’t mock, use fakes). I am not sure that applying all of them is possible, but in my opinion, the more you try the better your code will be.

Summary

Without any doubt, I am placing “Elegant Objects, vol. 1” next to my other favorite programming books like “Clean Coder”, “Clean Code’, “Software Craftsman” and “The Pragmatic Programmer: From Journeyman to Master” (some of them have reviews here on my blog). It shows a very different point of view to object-oriented programming and challenges much stuff we all take for granted. It presents something I would call a Radical Object-Oriented paradigm that will broaden your horizons and make you think twice before following any standard approach. There is second part named “Elegant Objects, volume 2” that I am planning to read as well.

Confitura 2017 – greatness delivered

Tue, 04 Jul 2017 00:00:00 +0000

Last weekend, I attended Confitura 2017. This year’s conference had about 1,400 attendees, 5 tracks, and 35 presentations; everyone could find something interesting to listen to and learn from. This post is a review of that great event.

A Bit of History

Confitura 2017 was the 11th edition of this Java/JVM/programming conference in Poland. When I realized the event has been around for so long, I checked my notes and found that I have only missed the first two editions. This was my 9th Confitura: twice as an organizer, once as a speaker (2nd best talk in 2015, yay!), once as a volunteer, and the rest as a regular attendee.

Confitura started in 2007 as Javarsovia. However, due to a mysterious company trying to ban the word, it was renamed to its current brand. It has grown from a single-track event to the biggest free-to-attend (with a small donation to charity) JVM conference in the country, featuring 5 tracks and over thirty speakers.

The Talks

When I reached the conference venue, I was surprised by the very short queues at the registration desks. Everything went smoothly—perhaps thanks to the use of QR codes as e-tickets. Within a minute, I had my bag, which even included a trendy fidget spinner toy! 🙂

Keep IT clean: mid-sized building blocks and hexagonal architecture in real life by Jakub Narbrdalik

Every time you attend one of Jakub’s talks, you can be sure your time won’t be wasted. This time was no different: a very good presentation on limiting class visibility as a step toward cleaner architecture, better testability, and happier developers. He also covered packages and subpackages, managing the visibility of Spring beans, and a high-level look at CQRS architecture. With Kuba’s talk, Confitura started with some very “meaty” technical content. Link to the slides

Studium przypadku wystarczająco dobrej architektury by Jakub Kubryński

The story of a startup and a CEO who needs to balance the eagerness to refactor with the cost of doing so. It included many useful tips on how to apply a “good enough” approach to a project, what to automate, and which metrics to measure to understand what is happening in your system. Kuba explained how they ensure microservices can communicate with each other (Spring Cloud Contract), why end-to-end tests should only cover the most critical paths, and why your users are often your best testers. Link to the slides

Reactive web services by Kamil Szymański

A live coding demo showing how to introduce a reactive approach to your project without using too many external libraries (using only the latest Spring and Hibernate). I respect all speakers who are brave enough to write code during a talk, and Kamil did it well, with only one or two minor pauses. He covered Mono and Flux from Reactive Spring as well as features from the latest Hibernate.

Evolving Architecture by Daniel Pokusa

A talk about the career of a software developer trying to understand what makes a “good” architecture and how to build such a system, while making some costly mistakes along the way. It was a very good talk, especially for junior developers; those more experienced might find some of the material familiar. Daniel mentioned several excellent books to read; I personally added the free Cloud Design Patterns from Microsoft to my reading list. Link to the slides

Visa Developer Center by Tomasz Cisowski

This was a sponsored presentation, so I didn’t expect too much, but the topic was interesting. I have some experience integrating payment providers and wanted to see what Visa has to offer. In short: visit developer.visa.com to check their documentation; they have many different APIs to experiment with.

Testy wydajności z Gatlingiem by Andrzej Ludwikowski

My colleague from SoftwareMill retold the familiar story that measuring performance is hard. However, with Gatling—a tool written in Scala, Akka, and Netty—performing these tests using its elegant DSL should no longer be a pain (we all remember the “great” UX of JMeter). Link to the slides

7 things which you should care about before release your code to production by Mateusz Dyminski

A solid talk about things like API versioning (especially important for mobile app backends), database migration versioning, and learning how to profile your code before you go to production. Lots of useful practical advice! Link to the slides

Plantacje programistów – kolonializm XXI wieku by Wojciech Seliga

I skipped this to do some networking instead, but I had seen this talk at GeeCON earlier this year. Wojtek argued that being “just a coder” is no longer enough; we should strive to understand the business better. We need to be more than someone who just writes code (which is becoming a commodity) and instead understand the product and the organization to bring extra value. He suggested that instead of just software engineering, we should focus on “product engineering,” which involves user experience, market research, data analysis, and more. It was a great talk with many interesting insights. Link to the slides

After-party

I cannot emphasize this enough: after-parties are at least one-third of the value of any technical event. If you have the chance to attend, never hesitate. You will meet speakers, organizers, JUG leaders, and many other fascinating people. You can talk to them about anything: their presentations, their open-source projects, or off-topic subjects like cars, kids, Lego sets, or even the strangest place you’ve ever pushed a Git commit from.

The atmosphere is relaxed, and since no one is rushing to the next session, networking is easy. Just grab a drink and join a group. “Spoina,” the party after Confitura, was great as usual. This time, we had an entire barge to ourselves in a very atmospheric location, with good food, plenty of drinks, and no loud music to drown out the conversation.

Of course, we didn’t finish there and eventually moved to the city center for the next phase of socializing! 🙂

Summary

As usual, Confitura delivered: great talks and even greater people. I saw many old friends and met some new faces too. The old venue (with its upgraded air conditioning) held up surprisingly well. Honestly, aside from there being too many interesting talks to attend and the breaks being too short to talk to everyone I wanted, I couldn’t find any drawbacks. If you are into programming, this event is definitely for you.

Credits: photos by @bartekzdanowski and miejsce.to

Rise and Fall

Wed, 14 Dec 2016 15:01:35 +0000

Far, far away from here there was a football league with many strong teams, some medium ones and a few struggling to survive. Every team wanted to be perceived as the best in the business as it would make signing new passionate and skillful players much easier. But most experienced players knew that there is a general rule applicable to almost every team: the ones paying the most are also the ones most likely to play boring, old tactic without a chance to learn something new.

Everything seemed to be stable – there were Team A and Team B and they were the best places to improve players’ skills. Teams C and D paid super high salaries and bonuses for goals, but at the same time they used old approaches far away from modern football. Knowing this, every good player could discuss the future with his agent to decide what is the best for him at a given point of his career as a professional footballer.

The Rise

But suddenly something changed – the league was joined by a new team – Team Z. Their sponsor was an overseas company with apparently endless amount of money to invest. Team Z took a different approach, the approach that was never tried before in this league – they wanted to pay the most and at the same time be a great place for any footballer to improve their skills. They hired one of the most experienced footballer in the league and soon made him a manager. With his renown and connections, Team Z was able to convince many highly skilled players to sign contracts and play for them. It was even easier as the wages were also one of the best in the league.

The first season was very successful, Team Z was playing extremely well bringing their owners what they have sought: points and trophies. Their tactic was fresh and effective: dividing game into very small phases that can be trained and improved separately proved to be what footballers like.

During that season they became even stronger: a big name, a really big one with many awards, joined their ranks. As a result, all these famous players and modern tactic made Team Z one of the most wanted place for any aspiring footballer and club’s e-mail was flooded by agents eager to put their clients there.

The Fall

And yet again, everything seemed to be stable: everyone knew that Team Z is a great place to enjoy playing football and earning good money at the same time. The team was strong, the morale was high. But then, out of the blue, something started to change. Rich investors wanted something else, they said: “We need more players in our team, maybe we should lower the bar to sign more of them”, but ex-player and manager in one person was reluctant to do so, as it could affect both morale and quality of his team.

Or maybe it was his experience that caused the tension to grow? After all, he didn’t have any business background and, as an ex-player who recently joined manager ranks, he tried to get best training methods, best shoes and best balls available on the market for his players, so they could play best football. But one reason or another, one day the manager left the team (or maybe was sacked?) and soon decided to get back to playing football in another club. Team Z was left shocked. They were sure that everything will change now, but no one knew what would the future be…

Club owners needed some time to find a new person to lead their team, a person more like them, more business-aware. And when they found him, every player was happy and with high hopes for a new, fresh start that will get them back to the top of the league. But month after month passed and they started to feel disappointed. New manager wasn’t able to win the hearts of his passionate footballers, he was concentrated on the league table and not on the players. Club investors were happy, but the team members were not. Salaries were still high, but morale dropped and as a result star players started to leave.

First significant loss was the team captain who soon was followed by a few other players. Another wave started after the season was over and bonuses were given. Each month was bringing news that some footballer from Team Z is joining another club.

And the worst thing was that now, when many people in football industry knew what was happening inside, the number of agents calling Team Z dropped significantly. To overcome this, Team Z started hiring footballers from another league, footballers that were not aware of the difficult history and unknown future of their new club.

Summary

Many pundits wonder how the future of Team Z will look like. Either they will find their form and recover lost morale, or stay in the mediocrity, looking at next leaving players and finding it more and more difficult to find valuable replacements.

Elon Musk – an amazing entrepreneur and a difficult person – book review

Mon, 07 Nov 2016 00:00:00 +0000

From time to time I like to read a book about someone extraordinary, with great achievements in some areas that I am interested in (like football, basketball, computers and technology), so when I saw Elon Musk biography in a bookstore, it immediately caught my attention.

It took me only three days to finish it, so in my opinion this book a good choice if you need some entertainment but at the same time you don’t want to deviate too far from IT domain we are familiar with.

Long story short

Author takes us for a journey starting from Elon’s difficult childhood and his first computer game sold for 500 USD to a magazine when he was 12. We read about his hard times at school when he wasn’t liked because of his intelligence and strange behaviour. After graduating from high school Elon left South Africa and moved to Canada and then to the USA. There he finished studies (with Bachelor of Science) at University of Pennsylvania and started PhD in applied physics at Stanford University only to resign after two days.

Elon decided to pursue his dreams and become an entrepreneur instead. He quickly succeeded and his first company Zip2 was sold for 307 million USD. He invested most of his income from this sale in X.com – an online financial service which was merged with its direct competitor and then renamed into PayPal. This company was sold for around 1.5 billion USD.

After this sale, he launched Tesla and SpaceX – his two the most renowned companies right now. The former builds electric cars, the latter sends rockets into space and aims to send astronauts to Mars and launch a colony there “making humans a Multiplanetary Species”.

Difficult personality

While being a successful man turning everything he touches into a well prospering business, Musk has a very difficult character. Book contains many proofs that Elon is a very, very difficult person to live and work with. He had two wives (Justine and Talulah), divorced with both of them and then married Talulah again. Recent news claim that they are in the middle of second divorce now.

He is also very demanding person. The main problem is that he demands extremely much not only from himself but also from all his employees. That led to many conflicts and caused many people to leave his companies saying that they respect him but at the same time they can not cope his pressure and treatment.

Summary

Book about Elon Musk shown me his road to current success. I have also learnt many small but interesting facts about his life and his work ethics. He is a very controversial person but I see him as a one of the potential candidates to really move forward the way humanity lives and looks at our near future. His plans (but also his achievements) are really impressive and I can’t wait to see how our planet will look like in 10-20 years from now with at least a part of his ideas realized.

Another interesting observation I made after reading this book is that two well-known people that significantly moved technology forward in last 10-15 years (Steve Jobs and Elon Musk) were really hard workers but also they were very harsh on their co-workers. Maybe, in the world where one-man armies can’t compete with other companies, this is the best way to achieve great things: demand much from yourself but at the same time demand even more from people around you and push them to their limits?

Credits: All images were taken from Wikipedia