We have just released the 80% milestone of our book "Stratospheric"! It's all about getting a Spring Boot app up and running on AWS and connecting it to some of the most important AWS services.

The new release goes into building a continuous deployment pipeline with AWS CDK, how to use AWS SQS to decouple our components, how to use AWS SES to send emails, and how to use Amazon MQ to send push notifications to the users of our app.

As long as the book is not completely finished yet, you can still get 50% off by signing up via the button below (and still get the finished version when it's done, of course).

If you're working on a single project, getting things done is usually quite easy. You just pick the currently most urgent (and hopefully important) task in that project and work on it. When it's done, you pick the next task, and so on. 

But how often have you actually been working on a single project only? Even if, technically, you're working on a single project at work, there are always other hidden projects that demand your attention:

• learning that technology you want to learn
• doing that certification you need for promotion
• getting started on that side project 
• managing expectations with your manager
• planning your career 
• ...

The further along you get in your career, the more projects tend to pile up, and picking the next task to work on becomes a chore.

I often find myself focussing on the projects that require hands-on programming work because they are the most structured (with a backlog, a sprint board, etc.), and, frankly, because they're the most gratifying to work on. I get results quickly and get to move a card on the board from "To do" to "done". Who wouldn't prefer that over fuzzy non-programming work that no one else (but yourself) will thank you for when it's done?

That means, however, that all my non-programming projects are stuck indefinitely. That's not good for my next performance review, since I'm not measured by programming tasks alone.

So, what helps to advance those non-programming projects? What helps me is scheduling the next task in each of my projects.

That means I schedule that meeting with my manager to talk about expectations in our calendars. While I'm at it, I also schedule 30 minutes in my calendar just for myself to prepare for that meeting.

It also means that I block 2 hours of time this week in my calendar to just think about my projects and career to identify the next things I need to do.

Just having those blocks of time in my calendar helps me to prioritize these tasks on the day they are scheduled. It also helps to keep that time free because other people see that it's blocked in my calendar.

I also add cards to my team's sprint board for many non-programming tasks I'm working on, even if they're only remotely related to my team's projects. This manages my team's expectations towards me. They now know what I'll be working on and what not. They might not really be interested in the results of some of my tasks, but I don't feel pressured as much to do sprint work, and thus have created some time to work on my non-programming tasks.

Ever ran into dependency conflicts with Maven? I'm pretty sure you have. Maven is doing a good job in trying to resolve such conflicts for us, but it's good to know how Maven does that so we can influence it.

In this new article, we take a look at transitive dependencies and how Maven resolves version conflicts. Then, we'll have a look at using a Bill of Materials (BOM) to manage dependency bundles.