Category Archives: General


Becoming expert vs great programmer

Just a month ago I have changed my job. After almost 4 years in a big company I realised, that I have to move forward. It become clear because of many factors but one of most important was the title of this post: becoming expert vs great programmer.

Becoming expert

When you start new job, specially on middle or junior level, you learn a lot. You gain experience really fast and you feel satisfied. After some time you are proficient enough to handle almost all kind of task by yourself. At that moment in time you know architecture of your project, tools and techniques used during development. Of course there are cases when you need to ask more experienced developers/architects about some solutions, but you are quite confident about your skill and abilities to handle those tasks.

From that point you wave usually couple of directions in your career:

  1. Practice your craftsmanship and master in detains all nuances of language/framework used in your project.Basically it is great to become expert in usage of some framework or programming language, but it is possible that after 5-10 years nobody will use this framework anymore (just for example look what happen to YUI – Yahoo decided to stop development of this framework, because front-end development went in different direction and big, good for everything frameworks are not cool nowadays).
  2. Focus on gaining more business knowledge.That is also good if your are really interested in some area, but after time passes by developers are usually bored and in longer terms are not good business analysts. Developers are people who need technical challenges. Working as business analysts requires more focus on human relations and understanding needs of customers. Gaining more business knowledge gives you also a chance to become Lead or Manager, but there are not so many programmers, who are good as managers. Usually when they start managing they have poor results.
  3. Start looking for new job where you can learn other languages/frameworks.That solution is quite interesting. The problem is that it is not easy to get job for which you don’t fullfil requirements. There aren’t many companies, which are willing to hire and train developers. Usually interesting companies are looking for senior level developers, because it is most cost efficient.

Becoming great developer

So what to do, when you feel a little bit bored in your current job and looking for challenges? In my opinion there are couple of things worth mentioning:

  1. Read books about programming in general, like: Clean Code: A Handbook of Agile Software Craftsmanship (Robert C. Martin), The Clean Coder: A Code of Conduct for Professional Programmers (Robert C. Martin), Refactoring to Patterns (Addison-Wesley Signature)
    etc. Those books will help you become better developer without being tidied to particular language/framework.
  2. Learn designs patters (Design patterns : elements of reusable object-oriented software
  3. Learn Test Driven Development (Test Driven Development (The Addison-Wesley Signature Series) and Behaviour Driven Development.
  4. If you have some gaps in you basic knowledge – fix that. Many times on interviews I ask people if they know how HTTPS works, what is the difference between TCP and UDP or between functional and procedural programming . It is surprising how many developers don’t have wider background. I know that it may look that this knowledge is not important during day to day development. But it is really important if you want to understand nature of some problems.
  5. Focus you work on creating solution with great quality and treat all of your tasks as exercises in applying things learned from points above.
  6. Learn some new languages/frameworks by going through tutorials and some pet projects.

Those steps will lead you to a place, where languages and frameworks are only tools and you focus on finding solution to a problem. From here you can switch your tools and be quite proficient in any other technology. Maybe you will not become expert in it in one week, but you will be able to create clean, maintainable solutions. And if you look from other perspective – stakeholder are not interested if you know how JVM handles integers smaller than 128. They are interested in getting their problems solved.

In my opinion great developer is a person who knows, that some tools better feet some problems. But in order to see this you have to get wide knowledge and this is harder if you focus only on business area or only on one language.
Moreover in the time of microservices and lean development, it is important for each developer to be able to switch tools as requirements change. It is fine if you are great Java developer, but maybe next week your boss will tell you to use Python to build a REST service. Are you able to learn new language and develop clean, maintainable solution after few days?

I think that way for becoming great developer somehow relates to Dreyfus learning model. In this model Expert is a person, who wants to get context in order to talk about some problem. He doesn’t use hammer and doesn’t see all problems as nails. He is free from thinking by his tools. He thinks about problems and solutions. I will come back to this model in future, but for now you can read more about this: here.

Becoming expert is not bad, but how many COBOL experts do you know today?

Agile General

Types of leaders by Roy Osherove

In my previous post The three team phases – from Notes to a Software Team Leader: Growing Self Organizing Teams by Roy Osherove  I was looking at team phases. Now lets check what types of leaders we can become according to Roy Osherove.

Command and control

We’ve all seen or have been this type of leader at some point. You tell people what to do. You are the “decider.” You take one for the team, but you also have the team in your pocket in terms of hierarchy, decision making, and control over everyone’s actions.

The command and control leader might also solve everyone’s problem for them. I once had a team leader who, on the first day that I joined the team, set up my laptop while typing blazingly fast on the keyboard and not sharing with me anything he was doing. When I asked questions, he muttered something along the lines of “Don’t concern yourself with this now. You have more important things to do.” (read that sentence with a heavy russian accent for better effect.)

With a controlling leader, there is little room for people to learn, take sole ownership of anything, or take initiative that might go against the rules. And that’s just the way things are.

This approach won’t work if your team already knows what they’re doing or if they expect to learn new things and be challenged to become better.


The coach is also known as “the teacher” and is great at teaching new things to others. The opposite of the controlling leader, the coach is great at teaching others to make decisions while letting them make the wrong decisions as long as there is an important lesson to be learned.

Time is not an issue for a coach because time is meant for learning. It’s like teaching your kid to put on their shoes and tie their shoelaces—it takes time, but it’s an important skill, so you’d be making a mistake not taking the time to let your kid to go through this exercise on their own, cheering them from the sidelines.

This approach won’t work if you and your team don’t have enough free time to actually practice and do any learning. So if you’re busy putting out fires all day, and you’re already behind schedule anyway, you won’t have time to also learn or try new things like refactoring or test-driven development.


The facilitator stays out of everyone’s way. Whereas the coach challenges people to stop and learn something, the facilitator simply makes sure that the current environment, conditions, goals, and constraints are such that they will drive the team to get things done. The facilitator doesn’t solve the team’s problems but instead relies on the team’s existing skills to solve their own problems.

This whole approach won’t work if the team does not have sufficient skills to solve their own problems (such as slow machines, talking to customers, and so on).


That was one of many great thoughts from Roy Osherove book. I will post some more soon. If you would like to read this book, please follow this link:

General Java

Geecon 2014

GeeCon logo

Thanks to my employer – Sabre,  I was able to attend GeeCon conference, which was taking place in Krakow, 14-16th May 2014. This event was organized in big cinema with multiple different rooms. Usually there were 5 speeches at the same time.  I think that this conference is getting too big. It was very crowded specially during coffee brakes, when everybody was going from one room to another. Also eating lunch on your knees is not nice thing. I know that it is hard to put in one place tables for 1000+ people, but maybe organizers should consider choosing different place for next year. The good thing was that, as in good cinema, chairs were very comfortable.

Besides that I enjoyed it. It was great pleasure to meet other developers form different parts of the world and also to meet my colleges from previous company.

Some of presentation I attended:

Day 1

Jurgen Appelo – The 7 Duties of Great Software Developer

Very interesting speech about things we should thing about in order to make our careers move forward. Jurgen is a person with experience in management and he wrote book “Management 3.0”. During his speech he mentioned following key points, for each he added most important question every developer should answer.

  • Motivate yourself – Are you aligning your work with your intrinsic motivators?
  • Direct yourself – What do you see in your future?
  • Educate yourself – How have you decided to learn?
  • Measure yourself – How do you track your growth as a professional?
  • Connect yourself – How do you diversify your personal network?
  • Brand yourself – How are you developing your personal brand?
  • Improve yourself – Are you improving by adapting, anticipating and experimenting?

Whole slideshow is available here.

Marek Matczak – AngularJS: Java developer’s real-life experiences

Very well prepared introduction to AngularJS, specially for Java developer’s point of view. Marek described basics and showed how to use directives and templates, how to create simple widget and extends html with own tags.

Ken Sipe – Go – The Language of the Cloud

Ken described Go language by comparing its features with Java. For me it appears that this language is step backward. For people used to Java it is less readable and more complicated. Unfortunately it allows programmer to do simple things in many different ways (like for example returning multiple values from function can be achieved by assigning value in the middle of the function and it the end). In my opinion in can be very error prone.

Gleb Smirnov – Mutation Analysis or What Code Coverage Doesn’t Test

Very interesting speech about using PIT – mutation coverage tool to improve quality of unit tests. Gleb was showing example of Apache commons-math analysis and time needed to run mutation tests for that library. Results are very promising, I hope I will be able to use PIT in my projects.


Tim Boudreau – Everything You Were Taught About Java Is Wrong

First speech of day 2. Tim Boudreau was talking about few issues which he finds problematic in Java world.

  • Inheritance is evil
  • JavaBeans are an antipattern
  • ORM tools are solving the wrong problem
  • Threads for managing I/O are a mistake

Very interesting presentation, but I feel that some ideas are not applicable for big, enterprise solution. There are really cool for small projects.

Peter Lawrey – GC Free Coding

GC is always a very interesting subject. This time speech was about dealing with GC in system for which latency is main concern. Peter has shown few tricks (two of them were easy, one was hardcore – override String class). Basically I think it was good presentation by subject is much wider and can be explored more.

Kevlin Henney – Seven Ineffective Coding Habits of Many Java Programmers

Kevlin Henney is an author of book “97 Things Every Programmer Should Know” and he had some interesting ideas about habits, that we have. Just to show some examples

  • IllegalStateException – why do we need Exception in name of this class – we know it is exception by its inheritance tree.
  • UserEntity – if this is entity we should name it User, that should be enough.

Kevlin also focused on layout of code, because he thinks that it has big influence of perception. Good look and feel of code can highlight important things to person reading it.

 Kevlin Henney – Worse Is Better, for Better or for Worse

Worse Is Better is really bad name for quite good idea. This idea was defined before agile started its race to glory. There is a point where less functionality (“worse”) is a preferable option (“better”) in terms of practicality and usability. Software that is limited, but simple to use, may be more appealing to the user and market than the reverse. (wikipedia).

Day 3

Jakub Kubryński – Spring Boot – and it is lightly again

Jakub presented Spring Boot – this tool can be called Spring Light, because it allows developers to create Spring based application really fast. It contains many predefined configurations and supports other Spring components out of the box. Great tool for starting new projects. I will describe details in future posts.

Tom Bujok – 33 things you want to do better

Tomek mentioned many different useful technics, to make our software better (like Lombok, Byteman, Guava, etc.) Most of them were used to reduce amount of boilerplate code. He also found practical usage of System.exit. When he finds //should never happen comment in code, he immediately adds it there, like on this example:

try {
} catch (Exception e) {
	//should never happen

Sam Newman – The Practical Implications Of Microservices

Microservices is very hot topic right now. Sam has given his 14 tips which can help everybody build, deploy and maintain microservices.

Michael Feathers – Beyond Error Handling

The final keynote of the conference was about error handling. Main point of this speech was that we should consider error handling as bad design. In some cases I agree with him, but there are situations where error handling is required. Few important notes:

  • Null passing is wrong – avoid it by using Optionals or NullObject pattern.
  • Having noticeable exception handling is wrong – basically error handling should be separated from business logic because in many cases it makes code less readable.


I think 2014 GeeCon was quite good conference. Of course there were some minor issues, but with event that big it is impossible to make everything perfect. Every such event is great opportunity to meet with other passionate developers (I don’t think others come to conferences). As organizers said at the end, GeeCon 2015 will also be placed in Krakow, so see you there next year.

Agile General

The three team phases – from Notes to a Software Team Leader: Growing Self Organizing Teams by Roy Osherove

In order to see team leadership from new perspective I decided to read “Notes to a Software Team Leader: Growing Self Organizing Teams” by Roy Osherove. It is very interesting book and I would like to share with you some of great citations.

As one of most important things Roy mentions three team phases. I totally agree that we always have to think about where we are as a team. Those phases are:

  1. Survival phase (no time to learn)

    “Survival” sounds dramatic and is as alarming as it sounds. It doesn’t necessarily mean coffee-stained carpets and a sleepless staff. I define survival as your team not having enough time to learn. In order to accomplish your goal as a leader (getting people to grow), you need to make time to learn, so your main strategy, or instinct during this phase is to get the team out of the survival phase by creating slack time. In order to slack time, you will most likely need to use a command and control style of leadership.

  2. Learning phase (learning to solve your own problems)

    You can tell you’re in the learning phase when your team has enough slack time to learn and experiment and you’re actually using that slack time. Slack time can be used for learning new skills, or removing some technical debt, or at best doing both at the same time, such as:

    • Learning and slowly implementing test-driven development, with people who have no
      experience with it
    • Enhancing or building a continuous integration cycle, with people who have no experience
      with it
    • Enhancing test coverage, with people who have no experience with it
    • Learning about and refactoring code, with people who have no experience with it

    In short, use slack time to do anything, and tack on the phrase “with people who have no experience
    with it” at the end of the sentence. Your main goal as a leader (in order to achieve your overall role of growing people) is to grow the team to be self-organizing by teaching and challenging them to solve their own problems. In order to achieve that, you need to become more of a coaching style leader, with the occasional intervention of the controlling leader, for those cases when you don’t have enough slack time to learn from a specific mistake.

  3. Self-organizing phase (facilitate, experiment)

    You can tell you’re in the self-organizing phase if you can leave work for a few days without being afraid to turn off your cell phone and laptop. If you can do that, come back, and things are going well, your team is in the quite unique position of solving their own problems without needing you to help them

    Your goal in the self-organizing phase is to keep things as they are by being a facilitator and keeping a close eye on the team’s ability to handle the current reality; When the team’s dynamics change, you can determine what leadership style you need to use next. The self-organizing phase is also a lot of fun because this is the phase where you have the most time to experiment and try different approaches, constraints, and team goals that will grow you and your team even more.

That was one of many great thoughts from Roy Osherove book. I will post some more soon. If you would like to read this book, please follow this link:


Stabilization and quality don’t go together

Recently my friend told me nice rule.

If you have stabilization period during your development and in the same time you are developing new features, than you cannot say anything about quality of your product.

At the beginning I didn’t agree. I thought that it is possible to work on new features and on old defects in the same time. But later I started to think about it. Now I’m sure that he was right, but my first understanding was wrong. I think this problem is more complicated that.

Let’s look at example of company Agile.


  1. They do Continuous Integration.
  2. They have automatic tests, but it is impossible to cover 100% of scenarios.
  3. They work with SVN and codebase is huge.
  4. Team is quite big.

Assume that they release working version of their product every 4 months and they spend one month in each release on bug fixing (in the same time they are starting development of next release).

What’s wrong with this approach?

Working on one code base with different goals – my first thought.

It can lead to big conflicts, when one team is working on defects and in the same time developing new features. Those who are responsible for current release don’t what to introduce any risky changes, refactor or reduce technical debt. Their main goal is to make product “stable” so it can be shipped. On the other hand, those who are developing new features are not afraid of making bigger changes, even architectural.

Moreover, looking from outside you are not able to say if some bug fixes don’t influence newly developed features and those features don’t introduce new defects. Some can say – let’s create branch for each release and then merge changes. That can work, but as always, we are only humans. Somebody can forget to merge his changes to some branch and whole team will lose time on investigating the same issues once again.

Stabilization – second thought

After some time I discovered that whole idea about having stabilization period is wrong. If you have big backlog of defects and you have to spend time to reduce it, than you are doing it WRONG. You should stop, rethink your approach, review process and decide where you want to go. If you want to be agile you have to provide shippable version of your product after each iteration. If you are not able to do so, stop where you are, clear your backlog, pay the debt. I know that sometimes it is hard – there is marketing, there are some contracts, etc. But without taking this step it will get only worse and worse.

Continuous Integration

As Uncle Bob said during one of his speeches: “If it is green, I ship it”. I think that this the most important change you should make in your process. You should be confident and trust your CI it the way that you can immediately ship your product when it passes all tests. Those tests should be fully automatic. Of course you don’t have to run all tests in one build. Your process can have some stages with for example only unit tests, than integration tests, than automated regression tests, etc. It is important to setup process and have full agreement among all team members and stakeholders.

There is one issue with this approach. Building that kind of solution and writing software with 100% coverage has to be top priority for whole team. If it is not, situation will not get better.

Moreover not having correct process makes feedback loop much longer. Without big test coverage you are not able to say when you break something until your user calls you at the middle of night.


In my opinion the ultimate goal is not to have stabilization period at all. There are multiple ways to achieve that, but the best is to stop what you are doing and redefine your whole process, approach and what’s most important – goals. This requires having strong team with strong leaders. I will talk about this in my next posts.