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.

Update...update...update

You can call it deployment or update, the idea is the same. You want to deliver your latest a greatest software to the rest of the world ... or just for your users...is a challenge you will face sooner or later.

Containerisation and tools like Kubernetes have solved the problem of orchestrating serverside application deployment and updates...so if you can (and it makes sense) bundle your app into a container...consider yourself lucky...DevOps will do the job for you...

...and Android / iOS apps are also covered thanks to the PlayStore and AppStore provided by Google and Apple.

...but for those who still develop desktop applications...huge things...that are not (or make no sense to be) bundled in containers because they run on the client machines...you might not be that lucky as pushing updates to machines you don't control, is not that easy...

I use CaptureOne for editing the photographs I take as an enthusiast hobbyist "photographer" and every time there is an update all the you get is a notification and link to donwload 150Mb of software...and run installers...hit Next..Next..Next....to get that new version.
The same goes for many applications... they just don't want to mess with the update systems...you...the user...should do the dirty job.

Thankfully the browsers (Chrome, Firefox...and I don't use anything else..the rest also probably) have figured it out how to get that update without asking you for download and install.


My latest task at the company I work for was to create an update system that would support all the products our department builds (desktop Java applications, RCP, SWT, Swing, and even headless Java apps)... all this with minimal user interference. It was a nice challenge...and it took a while until we figured it out how to do it in the less intrusive way...but in the end...I think it ended up great.
We learned a lot and that's also something important to keep in mind.

With this in place, at every sprint-end when we deliver new versions for each application we touch in a sprint, update packages are pushed automatically to the central repository and everyone will get the new version. A nice notification saying "Update is a available" and button that allows you to download the update in the background ... while you work ...and when is ready it prompts you for update...which is a matter of a simple restart. It will keep you settings, and everything you had so far...and you can continue working.

If you do Scrum and you commit to deliver every two weeks a piece of software, it is not enough to just build-it and store it somewhere...you have to make sure that it ends up on your clients machines.

That's when you can say...I completed an iteration.

Delivering the latest and greatest all the time...in the shortest period possible...allows the feedback to flow back to you...so you can react...and practice agility and respond to client demands.

Update is important...and it should be on your radar...it closes the cycle.

The rush for DevOps

DevOps became a buzzword and nowadays I feel that none understands it's true meaning...everyone wants to just do DevOps...but in their rush they end up inventing jobs and producing more work than solving problems.

For me, DevOps is the area when you combine development and coding with the software delivery and sometimes maintenance....and we live in a world when a true developer has to know the whole cycle...because that's how our world is ...fast and agile...where we need software out as fast as possible, there for the testers or the end users.

...but when your only job is to do DevOps, all you can think of is how many more steps you can add to the pipeline...and how you can use this or that plugin in the CI tools...and you tend to loose focus from the actual goal...remember? we are solving problems for our end users...with our products.

We have to find the balance...between too much DevOps and no DevOps at all.

When you end up having a DevOps team that is more than 20% of your actual development team than you might have to ask yourself some questions...and more so if that process you have in place for delivering software is so complex that none understands it...that's when you'll have too much DevOps.


Find your zen place and stay in balance...it does not matter what others think about your DevOps...until you deliver often and securely.

Raise your voice or stay quiet

There are sometimes things you hear in meetings that can push you to the edge of patience...like "there is no time for this now"...or "that was not planned"..."that's way too much to work, let's do this hack now and we'll come back to it later".

If your goal is to deliver the best product you can that serves your customers, these sentences will always make you angry. The question is do you speak out? ... do you raise your voice and share your concerns?


There are the situations when someone from the team comes with an idea of refactoring a part of a product...and although technically it could bring obvious benefits to the code structure.... but it just feels wrong...
The code he plans to refactor is working well...in production ...for so many years....and besides the nicer code, there is no added value for the end-user...it is something for us, developers...a nicer (trendy) framework...or just a different view of the same problem...but it gives us work...to fill that backlog.
...will you raise your voice?...and maybe convince the team that this is not beneficial on the long term?...although you probably would like to use that new framework....


...or there are case when someone, in it's rush to accomplish a task creates a new mini framework...because it is more fun and challenging to create than reuse...will you raise your voice?


...or when a customer is quite explicit on what it needs...and the management tries to steer that towards a product that is already in the portfolio, that's not quite the thing the customer wants...and delivering what the customer requested is a matter of few hours extra work...but the management tries to spare that work....will you raise your voice?

...and there are so many situations, when decisions don't make sense for you....will you raise your voice?


Almost in any any case, when you raise your voice and face up your superiors or colleagues on any objective topic, you will create waves...and depending on the company culture, the waves can be surfed upon or the'll create a tsunami you will fall victim of...

If the later is true, your are working for the wrong company.