My Work in March 2018


The year has started well for me. Since my last update I’ve been busy working on projects that I'm passionate about and keeping up with my activities outside of the IDE - still dining out too often, and enjoying my music.

In terms of balance between work and play I’m happy with how it’s going right now. I get about 12 hours in a good week to work on my own projects in my own way. Because of the nature of the work and my interests, a lot of that is bootstrapping or dev-ops type stuff for a new technology I want to try out. Sometimes that works and I stumble upon a gem.

In the Office

I’m very happy with my day job. I work with wonderful enthusiastic people on projects that are never static. There’s a constant drive for new features and improving the current user flow. There’s also a desire to expand on the technologies, keeping up to date and trying new things.

I work for a firm that writes primarily in Java for the Fintech industry in Leicester. A year ago I had no idea about Java's application in the real world. I wasn't confident about systems development in general. A year on and I’m very comfortable with ideas and techniques that thrive in modern software development.

On the main project I’m assigned to, we’re in a team of five. It’s a fairly sized system, with around forty screens at a rough guess. It uses Angular 4, with plans to upgrade to the latest very soon. After a very large epic we managed to migrate it bit-by-bit from its previous framework AngularJS.

The migration was tough. For months we had the system in a hybrid state, booting both Angular and AngularJS in tandem. Angular allows this with many tools and classes that can help in downgrading components for the previous framework. It would have been very difficult to keep a separate branch whilst maintaining our pace for new features and improvements.

The back-end is a Spring web system, connected via a REST API. Spring makes writing Java a joy, and I can’t wait to have an excuse to try the latest version with better support for Kotlin.

I'm very happy with all aspects of my day job. The potential for what's next keeps me excited for every day. I feel lucky to be in this position.

On the Side

I've got many projects on with a variety of customers in various sectors. Most of them are brochure websites built on WordPress, but I'm also working on a project that might replace my need to depend on it.

I'm far busier than I have been for a while. I'm managing to almost keep up with it all, but the pace I promise myself and others does not match up to the pace at which I can produce.

To fix this I'm trying to collaborate so that I have more freedom and stricter concerns. The last few years I've been fortunate to have learnt from some very experienced senior developers. One of those lessons is escalation. If there's a problem, shout early, and shout often. Seek help, and don't stay stuck for long.

In an ideal world I'd concern myself with the designs of the products, the proposals, the development and a bit of the environment. Dev-ops is a tough one, because the landscape keeps changing as it does for most areas, but the hope is to have something resilient that you can scale. This is often harder in practice.

I would like to have a few areas that I'm less involved in, such as client relations, marketing myself, service and support, acquisition, and especially negotiation. I'm fairly terrible at these, and I sink a lot of time into admin that I struggle to manage.

Areas for Improvement

I've already gone over what I've escalated and started to bring about change on, but there are other areas that stick out like a giant elephant in a cramped room.

Behaviour and Test Driven Development are modern practices that have seen software development methodologies flourish, allowing fast iterations of software and systems development with a high confidence of quality assurance. I don't need to be an advocate this, the results of this in agile teams speak for themselves, loud and rightfully proud.

In my day job I'm working in a fast paced environment, with a fantastic team of Business Analysts that manually assure the quality of a system, as well as providing domain specific knowledge which allows developers to focus on moving fast.

Now there's contention there in two parts. Why is the quality assurance process manual, and why are the developers not concerned with the domain?

In another spate of "things I should be doing that I'm making excuses for not doing", I've yet to properly get stuck into Domain Driven Design. I think I understand its very basic principles, being that the abstractions of your code should match the behavioural goals of your domain.

I work in domain that I don't fully understand. The domain experts make it their job to fill that hole, and the senior developers have got their domain knowledge from osmosis.

In an ideal world a developer would have more or even a complete knowledge of the domain they're working on. How can a developer be expected to write for a system they do not understand?

In the real world a developer must learn from the bottom. If I had been thrown in to the domain of the Fintech industry, there's a very strong chance I wouldn't have thrived. To learn my role as it is was challenging. I don't think I would have been able to contribute or learn to the standard I'm at now with extra pressure.

And the same goes for behavioural and a test driven process.

But at some point soon a I will reach the ceiling of what I'm doing now and will need and want to concern myself with domain knowledge and test driven development.

Going Forward

In my day job, we're constantly growing, as individuals and as a whole, as should any role in any job. One of my key likes about the office in which I work in is the prospect and visibility of change. We try things. Some of them work. On a technical level, and a managerial one.

Personally, I need to embrace the things I'm not doing. Making excuses isn't going to teach me. An understanding, a desire, and a plan followed by action will.

I've improved at managing myself over the year, in planning and action. For my side projects I have embraced Trello and Google Inbox to make sure that I leave no person or action left for too long. This requires planning and strict prioritisation. If an action or person gets left behind, there's a damn good reason.

Tests start with the developer. In my day job, for our next release (I should've probably noted that our specific team works in a Kanban-esque routine) we will put time into getting our pipeline up to scratch, with automated end-to-end tests. We have previously attempted this, and our lessons from that increase the outcome of any future attempt.

Tests aren't sprints. When working with what is in effect a legacy system, you need to spend some time bringing it up to par. There's no excuse for us letting it slide or not adding tests immediately to the features we add. We have a framework now, and we will run with it.

I haven't touched on how to solve the lack of domain knowledge. I haven't given much thought to a solution. Learning by doing works for now, but at some point myself and the developers around me will have to do more to acquire domain knowledge and implement a process.

Enough with the Excuses

One of my worst development sins is calling a project or deadline knowing full well I am not going to make the finish line. It's lying to myself, with the hope that the blind confidence will lead me through.

Another one is being very distinct in my analysis. Calling things black and white that are not.

Learning is a series of mistakes whereby you eventually stop making them. For years in my work in and out of the day job I have made mistakes. I don't feel shame for this, but when those mistakes are made again, I do ring the alarm bells.

I didn't used to. I'm shy by nature, and have tendencies to silently fail, without escalation.

This has been the biggest change in my working process and I'm glad to say that my line-manager is now sick of my voice. But I don't often go to them with the same issues. I move up, and find new ones. I learn from the old ones, and help share the knowledge.

This time next year I hope to be in a position where I am asking less questions on development and providing more answers. The questions next year will be on the subjects I've highlighted here: the domain, the development processes, and the managerial practices.

Here's to another one. If it moves as fast as the previous, I'll probably be there before I've caught breath!

About this Post

This post started as a catch all for my usual updates, but with a bit more detail. It soon turned into a 3,000 word essay, with twelve points merged into a single post.

I've had a few ideas spinning around. The difference now is it's in a system where I can track it. I can review, add notes, and prioritise ideas (go and sign-up for Trello or similar right now - unless you already are).

I took the monolith post and split of the first two headings to present a more coherent series of points.

One of the reasons behind delaying the post was I wanted to showcase what I haven't yet done. I'm happy to say that bar the meta paragraph, all of it is a retrospect, not a flaky promise.

I took the 400 words and by the time I finish writing it'll probably be 1,800. I'm glad I could flesh out some finer points, rather than cram in everything on my mind like a huge word vomit.

I like this model and going forward we'll see how it goes.

Thanks again for reading.