Small wins

I recently moved to a new team within the firm. I was “hired” as an architect/infrastructure designer: this is a team with close to the business and they’re lacking some hard-core technical/technological people. I was a really good match for what they’re trying to achieve. They (and now we) have an old calculation engine that has all the shortcomings from the last decade of software design and development: uses XML heavily, has too many abstractions and it tries to be too smart by allowing too generic things. I’ll be looking into redesigning this while also upgrading the overall architecture of the systems we own. I’ thrilled to do this as I think this is where I want to lead my career.
The first couple of days have been sent with getting familiar with the environment, people and everything. Just out of fun and interest I spawn up a JProfiler and run some huge calcs through the engine. Surprisingly, the top three hotspots were very simple functions – that were called way too many times. One of these was actually just returning the same value 97% of the time, but delegated all the calls back to the parents in the hierarchy. It took about 80 seconds while the calc only used 200 seconds CPU time. It was too apparent that this is the place to start. So I analyzed the code and added some caching where I knew the value can’t change, sparing the huge call chains. I managed to reduce the 80 seconds to around 1-2, dropping CPU usage by 40% for huge calcs (the optimization is not that significant or smaller ones, actually).
When I explained this to more senior people in the team, they were surprised that this was a hotspot – they never imagined it would even come up in a profiling. Then they really like the caching idea. Then the news started to spread, and when I got to talk to the head of the wider team, he already mentioned that he heard that I already cracked the engine and that we’re saving a lot of time :) I explained to him what happened and how it works and that it won’t be reducing time of calcs by 40% as we’re still waiting a lot for IO.
I think this was an easy small win for me: I knew what to do, did it and already made my name heard in the team. I’m not saying people should start playing the cowboy in their new positions, but it’s always worth it to show what you can do iff you have the chance.

Managerial tasks

My manager has been away for three weeks. This left me as the person in command for everything related to our project. Unfortunately this didn’t get me out of my own tasks, leading to challenging weeks.

At the beginning, it was very overwhelming – I needed to run two sets of daily stand-up meetings, I had to answer almost all emails coming from our clients, I had to handle other client meetings, and -most importantly- I had to make a lot of steering decisions. My only issue with the latter is that I don’t feel that I have authority over things and people. Surprisingly I started to notice that team members (who are actually my peers, not subordinates) do require some form of “leading”. They had various questions on small things and a lot of times they felt lost without some guidance. I haven’t noticed before that we had to make so many decisions on various levels starting from Ux and minor code changes to actually setting future direction for many-many things. What I had found useful is getting into a system to handle all these separate threads of work. I started taking notes in all meetings, went over emails multiple times a day to make sure nothing is missed and eventually got the hang of things. It was a good, eye-opening experience. I also feel that I proved that I can handle these types of tasks as well. The only thing I’m not really sure if I actually want to in the future :)

I imagine my career more of as an architect/tech lead. I have no problem coding or managing people, but ideally I’d like to focus on bigger things related to technology.

Being the keeper of the fragile status quo

I’m not really sure why, but lately I’ve been finding myself in situations when I need to be very diplomatic and basically serve as the peace keeper. It might just be adult life, me maturing or just a coincidence, I don’t really know.

My manager has been on vacation for a week (and will be for another two), so I inherited all his responsibilities. This means that I need to find the balance between client requests and things that we as a project need to accomplish – these of course might not have direct impact on new features or bugs but will be beneficial in the long run. I need to drive the interaction between to more senior guys who basically can’t stand each other, because we need some bug fixes from them. I’m also responsible for keeping the team move without glitches; this means finding acceptable compromise for all members.

On top of the regular “work drama”, I’ve also found myself excusing some parts of my extended family to others. Trying to keep the peace and relative smoothness between my parents and in-laws plus wife and parents – giving it a little more thought, basically all the combinations that you can think of.

Maybe I just really grew up by now? Maybe before I didn’t really care for what people thought of others or how they felt? Anyways, I’m finding myself becoming more and more diplomatic. I also use this newly found ability to navigate storms to my advantage.

Does the fact that I only noticed this now mean that I’ve been so naive for not realizing this was such a huge part of life?

I envy C/C++ programmers a little

I have found this post on HN, and while I read through it, I had a strange thought. While I do coding professionally (aka do my job), I take care of much higher-level problems much more quickly (you could say in a bigger hurry). I realized that I envy people who can afford spending so much time and effort investigating and solving such a seemingly trivial problem. I’m not being condescending by all means here, I just find it interesting that some people has the blessing of actually handcrafting so little parts of a software system. I never get to spend a lot of time on such little pieces. Yes, I do optimize, I do try to be smart and there are times when I have the luxury of coding features for days uninterruptedly, but it’s usually not the case. I think about my code as a woodworking master who designs and creates furniture: I pay attention to little details, but use a lot of bigger pieces. Sometimes I miss playing with small Legos.

Workspace upgrade

Unfortunately my old 24″ Samsung monitor died yesterday. I have been thinking about upgrading my monitor setup for some time now, so this was the final push I needed. I bought a 29″ ultra-wide monitor (LG 29UM58-P). So far so good, I’m still getting used all the horizontal space and the vibrant colors. I’m keeping my other 24″ for now, but I might end up buying two smaller monitors to put on both sides of the 29″er.
Edit: Having the IDE set up like this feels just right
(Project structure|Code editor|Console output/debugger):

Trust me, I know better

Today I was working on fixing some unstable tests. We use Gradle as our build tool, and we’ve built so much on top of the regular Scala-Java-Javascript plugins that it’s staggering: our Gradle files contain more than 50K lines. We added abstractions, IDE management tools, complex test and binary generation with application outputs and startup script generation. There’s probably much-much more I don’t actually know about as I’m not a build infra developer. Most of these features try to hide and abstract away the complexities of managing the largest Scala project in the world (and all its little side modules). While I was working on fixing these tests, I wanted to simply print a value to the console to check if the test infra picks up a runtime dependency correctly – both on developer desktops and on CI servers. I wish it was as simple as that though! Gradle itself redirects test output and on top this we also forcibly change the logging settings so everything just works. Except when you want to do something out of the ordinary. I needed to start googling for vanilla Gradle solutions to find out how we actually do it by digging around in our code. It took me good 20 minutes to figure out this seemingly simple thing. It turned out all these were hidden away in some test configs and dependent properties. I managed to achieve what I wanted in the end.

When similar things happen, I really miss simpler days. I feel that most of the time we, developers try to fight a war of I know better. Most of us think that we’ve covered all use cases, all the little configurations are straightforward, the documentation lists all possibilities and if not, well, it can be figured out as it’s all logical. I can see the same thing happening with how the new way of JavaScript development happens in the world: you should use a couple of tools and libs that hide almost everything from you: dependency management, language and browser differences; even language features! All this so we only need to care for what’s important. This is really nice from the outside, but as soon as you need to walk off the regular path, you find yourself in a nightmare of multiple levels of abstractions, hidden little tricks and things that only a handful of people know about. I also understand that this complexity needs to live somewhere, but I feel we’ve gone a bit too far. The learning curve has become steeper than it was ever before.

Unfortunately I can’t offer a solution at this point – not even hypothetical one. Sometimes I just simply start daydreaming of good old days when everything was simple. Or at least simpler.

Add people to email chains, because that’s going to solve the problem!

There has been a systematic issue with one of our CI jobs that runs automated Ui tests. I have sent out an email to all users who hit this issue when it was triggered for their commits, stating that we know of the problem and it’s being investigated and it’s highly unlikely that the problem lies with the failed tests. One of the people I’ve sent this email to actually added the owner of those tests because he didn’t see how his changes could have affected them. I had to explain once again that the issue is systematic and it’s currently being looked at. I also started a discussion with the team managing CI jobs so we could look at the problem together. After some time, the new guy replied to the original thread, and of course added some other people because they should be also involved. This was the third time that I had to explain what was going on, and that we were working on the issue. I also attached the other thread I had with the build team, just in case.

I feel that there’s this fallacy that talking about problems will get them resolved. Talking is more effective if more people do it, so it only makes sense to broadcast everything, even though there’s no chance others can help actually fixing the issue or even if all possible actions have been taken towards finding a resolution. These then cost people working on the actual fixes time and effort, hindering getting it done. But since all these people felt involved, they also think they were part of the fix too. It’s an ego and visibility boost.

The very same thing happens when a client’s request is prioritized and actively looked at, but they insists of having daily catch ups, because sure, that’s going to speed things up! There are hard problems that take time and concentration; continuously interrupting people doing creative work never have helped in human history. What I don’t actually understand is why people doing creative work still do this to others. It’s like they think rules/suggestions/recommendations only apply to others, never to them!