Avoiding conflict

I hate conflict...mostly the one caused by subjective ideas, decisions...there is no win-win outcome from those...only frustration.

When you are assigned to work on a task and you make decisions on an area which ha no standards to follow there is always good idea to discuss with others....to ask for objective feedback...to make sure your view is not definitely wrong...

It sometimes happens that by asking for feedback all you get is subjective opinions which are not backed by facts ...and if you try to disagree or ignore these kind of opinions ...when these do not move you further....you end up in conflict...causing tension... and called an arrogant...d**k.

Feedback about a work item should be objective...apart from personal opinions...this means being a professional. 

Subjective feedback should be listened to, but it is destined to be ignored most of the time....so don't be surprised if your feedback is rejected.

If all you have is subjective feedback, than make it clear that "if I would have to do this I would do it like this...because..." This can...for those few open minded ... start a thinking process...and eventually maybe lead to a better solution.

Don't force your subjective ideas on others...let them decide if they want to listen or not.

... eventually time will prove you right or wrong...and it is ok to be wrong from time to time.

Upgrading the technology stack

If you develop software chances are that eventually your state of the art technology stack will fall behind...something that once was great stuff becomes old and outdated.

Using always cutting edge technology is simply impossible in a bigger company and bigger projects...as with every technology stack update you introduce regression...and since the customers have no direct benefit from this...eventually the company will cut the effort for staying up to date.

Something that works should not be changed unless there is a good reason for it.

And so we end up using Ant+Ivy and CVS and Java 8 in 2019...where everyone is using Maven and Gradle and Git and Java 11...and you have to argue constantly why...

Upgrading the technology stack of a department is not that simple...we have to move slowly and cautiously...and we will get there...and products will not suffer.

..and everyone will be happy...except those who will not.

Key persons

A key person is someone who's presence is absolutely required to resolve an issue...develop a feature...decide something.

When such a person is missing...is out of office by some reason...things tend to get stuck.

To avoid these situations the software development processes have evolved and they came up with the idea of cross-functional-teams and peer programming. These make sure that a knowledge about some topic is shared at least between two people...preferably with the whole team... nice and easy...no more key persons...done.

Thing is that there is a certain type of knowledge that cannot be shared...and this is experience...the luggage you are building during your professional career...and in some cases this is the key knowledge that makes the difference between you and Joe/Jane.

...but assuming that everything would be a shared knowledge ...and every team member could pick up your work and be able to continue it...how valuable would a person be in a team? ... what would be the difference between you and a factory line worker? ... companies would love that...right?

As much as some companies would like...there are roles in this domain where people are not interchangeable...although knowledge is shared...you will not be the same as Joe/Jane...and these persons will be the most valuable asset in the company.

There will be always a certain type of persons with that key knowledge...and you have to live with that.

Vacation period...when you work in a team

Vacation period is the time of the year when sometimes several colleagues from your team are out of office...This is the time when if you have a task that depends on a work done by a colleague left for vacation...most of the times there is little chance that you can complete your work...and you might end up blocking others...and so on.

This is the least productive period of the year.

Maybe it would be better to just call the period...and abort the mission of delivering something significant.

This would lead to less work to fix later...and less frustrated colleagues.

Just accept that there are times when is better not to commit anything....and no worries...things will be finished eventually...when everyone is present... physically and mentally.

Can you be a specialist or everyone is a "Jack of all trades"?

A specialist is someone with a focused knowledge in a domain. The level of the knowledge is not mentioned usually...and so nobody can challenge the specialist status....so it's mostly on you to call yourself a specialist.

So if you know something just a bit better than something else, can you say that you are a specialist?

Let's say I am a Java specialist/expert...is this enough for me to design and write a network application...and deploy it? ... Or do I need some knowledge about deployment and network architectures?

...or if I am Spring specialist/expert than is that enough to know how to deploy my microservice to a Docker container? Or should I know how to write Docker files...and use Jenkins to build the image for me....

You can be a specialist in a technology...framework...whatever...but you also need to know tons of other things too...to live in this IT world.

...but if you know so many things...than there is little chance to be specialist/expert in all of them...right?...unless you are Tony Stark.

...than can you look in the mirror ...in the morning...and call yourself a specialist/expert/senior developer? ... than why the titles in the email signature?

Economy decisions... with other expenses

I had a busy, week....and I think anyone can say this. Being busy does not necessarily mean being productive....it might mean just occupied instead.

Recently, together with my wife, we attended a Bon Jovi concert in Bucharest...being my wife's favorite music band, we decided to go.
There were two options:

1. Go to the concert in Vienna (about 500km and 4.5h, almost 100% on highway)
2. Go to Bucharest (about 660 km and 9hours drive, about 20% on highway )

The difference between the two was the ticket price, which in Austria was about 20 % more. Considering this and the fact that historically the concerts have been more engaging in Bucharest we took the economy option.

It was a long weekend...and a great concert...

Romania is a great country, with very nice places...and as some used to say "pretty bad that it's populated".

Bottom line is that sparing that 20-30% on the tickets, made us spend more on travel...invest more mental energy in coping with a wannabe European capital and it's inhabitants.

My father had a saying which goes something like this: "You did not overpay...just worked more for it".

How many times do we get in the same situation...when we cut corners...because that's the cheapest way to solve a problem? ...and than over time we end up just working more to fix things...

In some (most) cases, economy is not a way to go.
Using an open source framework...or just a free thing for your long term product might get you there faster...but how much will you invest in learning and getting to know the code...and later maintain it?

Choose wisely...or leave a door to opt out later.

Giving a presentation

Usually at companies when you start advancing in your career it will come a point when you are asked to give a presentation...to share your knowledge.

Giving presentations in front of an audience, is a great thing to do...you can learn a lot from that experience.

There are people who are complete naturals when it comes to giving presentations...they are just brilliant ...engaging ...funny....and of course there are some who are not so great at it....some of them are terrified...and try to avoid this experience as much as possible.

I like to think that I am somewhere in the middle...not a natural talent...but also not terrified of the experience...I tend to say I like it....I like the journey....the preparations...and if things go well also the excitement on the faces of the participants...that you managed to deliver the your message...and sometimes give them things to think about...that's the reward.

The company I work for, started organising internal conferences a few years ago...mostly for the staff...as a kind of knowledge share event. These are great opportunities to learn about what others do in your department...or even in other departments...a great chance to talk to others about the experiences...and share your knowledge...your craft...

I usually push myself to present something at these events...I did so at every event...just to extend my barriers...learn and experience new things. This time...for the first time in the history of the conference... I decided to do a live coding session...build something from scratch in front of the audience. Being a first time ...also for me... I think it went decently ... although I did not manage to finish what I planned to do... (lesson learned about that) ...but at least some people seemed to stay interested in the presentation...the room was packed...and they stayed till the end...and even asked questions...so I think the message went through.

Doing live coding in front of an audience is almost like doing peer programming...but with more people looking at your screen...way more people...and on top of that people who don't know the framework you are using...so besides coding you need to explain...a lot...and give context...about why you do things a certain way...

Someone said that at some point...when I was notified by the session chair that time is close to being over...the whole situation was like in the Swordfish movie, when Hugh Jackman is threatened with a gun to finish the work on a laptop..in 60 seconds...(https://youtu.be/mWqGJ613M5Y?t=78)...of course without the motivation factor...if you know what I mean ;).

It was fun...a great experience...and a great opportunity to learn...about myself...

Giving presentations will always teach you something...and I think everyone should do it...from time to time...you will not regret it....and if you have no audience at your disposal...there is always Youtube...do a presentation and record it...just for the sake of doing it.

Being a lone wolf

I have a lone wolf side in me... that makes me do stuff on my own...without asking for help.

Probably this is how I always been...but now I start realising what I have become...and there is a scientific reason behind it...apparently.

At the company I worked for during the past 11+ years I got several individual assignments...and I was really grateful for them...and until we switched to scrum, I was formally not part of any team...I was the framework team...alone.

Needless to say I like working alone...that's when I am in the zone...I can focus on the work...the challenge and get things done...quickly.

Working in a team is a different kind of beast...and I can argue that some things are harder to be done in a team than as a lone wolf... let me rephrase: some things are more efficient while done alone than in a team. This is what I learned in the past years. In order to have something done in a team, there is communication to be done...and if you have a complex idea you have to communicate it to others...and by the time they understand it...many long meetings will pass...and no real progress.

I am a software craftsman...I would say an efficient one... and some things do not appeal to me...like doing long hours of explanations to a team...not interested at all in my topic...just present because they need to...just so that you can feel that you made something in a team...In that time I would probably done it already...on my own...in my cave.

I enjoy working in a team if I am not leading...if there is someone else who takes the responsibilities of architecting and leading ... and I can fill in my work  as a black box... I'll do my share...my chores...and help others while doing so...I am a good team member....asking the appropriate questions...but after so many years in leading...you cannot go back...they expect you to lead....you are trapped.


I think I could go back to that obedient mode...no more "lone wolf"-ing ...just get back in line...while I gather my strengths... and learn a few new crafts... and I find the things I lost in the past years...

Quarter release

I work in a product-team, that focuses on delivering a set of base products (and frameworks) for the teams that are customising these products for paying customers (around 7-10 parallel projects).

The customer facing teams should base their work and deliveries on stable product versions that are supported for longer periods, like LTS (long term support) releases. This is what we call quarter release.

Our development process resolves around 4 quarter releases in a year named by the pattern <year>.<release in a year>. Each quarter release is prepared in 7 Scrum sprints each two weeks of development.

Each release means end of a development branch and start of a new one. We always work on an active quarter branch...only one active branch at a time... the released branches are kept for bug fixes and long term support ...for 2 years.

Inside a quarter the, code will always stay backward compatible...features are added....changes are done...but nothing is broken...just marked for removal.

Doing a quarter release means creating a release build from ~100+ modules of ~9 active base products. The process takes around two days and part of this process is automated part of it involves some manual tasks....nothing standard...but it is working...

Quarter releases give certainty that the release version is one stable codebase ... and that it will not be altered unless requested....they need to remain stable...and supportable.

Quarter releases are like putting away the past and embrace a new beginning...

This week I did the 19.2 quarter release...took a deep breath...and starte working for 19.3

So your product has matured...now what?

If you work long enough on a product you will reach a point when there is nothing more to do...besides maintaining and fixing bugs.

You are done. The product is done...ready....clients are happy...problems are solved...time for the management to milk the cow....

...and while they pick the fruits of the product...you can focus on the next big thing.

...truth is that big things are not so easy to find...and make...you either have a clear view on what clients might need...and leverage that knowledge...or you need to keep trying...and trying...until you find something...worthwhile to build.

...and what if the product has matured but is not good enough...you know you could do better...maybe differently...and this new approach could open new opportunities...and happier customers...

Should you find new markets?...or please the current market...better...

From a budget point of view...building a new iteration of a similar product is a risky path to take....

will it pay off?...will it sell? ...what if the clients will not like it?....

...and how about doing both of the things?...search for something new and in the same time iterate on that established product...while the old version pays the bills...

...in the end we should solve problems...right?

Goals...goals

A goal is something you would like to accomplish at some point...in a limited time...a target you want to hit.

Having goals in life ...and in work...gives you a sense of purpose...something to aim to...something to strive for. These are the light at the end of the tunnel...the ones you focus on when walking on the path.

With goals set ... you can always check where you are on the path...where do you stand...and the path leads to the good direction.


Goals can be either material or intangible but they need to be specific, motivating, attainable, relevant and most importantly trackable.

Setting goals is not an easy task but it is worth the effort. 

When you work for a company and you are required to set some goals as part of a personal development process these goals need to be inline with the goals of the company...your goals need to be relevant for the company...

...and when a company stops having goals...or has goals that are not relevant or motivating for you...than things might be not too bright.


Should you reconsider your goals?... or should you be worried?...or just give in and pray for the best?

...or should you step in and push for bigger goals than paint a goal for the company too?...

Technology is the tool

When you need to solve a problem...you focus on the problem.
Nobody asks with what tool did you fix the broken door lock...they acknowledge that it is fixed...most of the time. They might ask how long did it take or was it hard to fix...but not with what.

The same goes also for photography. When you take a great picture, people will notice and hopefully enjoy the visual "candy bar"...but quite rarely will ask about the gear you used...maybe about the technique ...if it is something more complex.

Why does it mater what kind of technology did you use when you made a REST endpoint that serves a particular task. It does matter to you...the author ...and it might matter to the maintainer...but certainly not for the end user. All the users care ...well most of the time ... is did you solve their problem or not.

The tools are yours...you are using them...you know about them and their limitations...and things should stay this way.

Balance...

Being a developer with family is like trying to joggle with several balls  in the air. When one falls down the whole show is ruined.

In the past few days I was engaged in an activity at the local Waldorf school and I had to put work aside. Thankfully I work in a position where you have a chance to be flexible...in this case I decided to make up for the lost hours in the evenings and in the coming weeks...partly because I have eaten up my vacation days...but also because I need to feel that this is not vacation yet. The tasks were not delayed, and I managed to close all my Jira issues so everything seemed to be fine...besides the missed daily meetings.

Spending time with my family is a great thing and maximising this time is an important benefit, this type of job offers, besides the monetary remuneration...of course.

But on the other side...I love what I do and not being able to do it for a longer time creates a certain stress ... and I feel out of balance.

The planned vacations...those two weeks when you close shop...are the ones when I completely disconnect from work...and focus on resting and maximal enjoyment of life. In that period the balance is kept by other things...work is not part of the formula.


Things need to stay in balance...regardless what you do. Too much of something will affect the other areas...and things will fall apart.