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.