Two years ago I signed up for my first Tough Mudder. The plan was to do it together with a friend who did it a year before that and told me about it. Unfortunately he injured himself before the event and couldn’t participate, so I ended up running alone.

This was not optimal since these kinds of events are team events. Many of the obstacles are nearly impossible to tackle alone. But the good thing is: You are never alone. Except maybe when you are really slow and started late. Other participants will help you at the obstacles!

And in my case a team of women even spontaneously included me in their team. They were rather experienced with this kind of race and told me that while they enjoyed the Tough Mudder they liked Xletix even better.

After doing the Tough Mudder for a second time last year this time with a small team we decided to try Xletix as well. After signing up I got curious: How does Xletix compare with Tough Mudder? For some reason I could hardly find anything. So here is my comparison of the two. Note that both events have instances all over the world and I have no idea how the same event at different locations differs. This comparison is just between the “Long” distance of Xletix Berlin Brandenburg and Tough Mudder Nord-Deutschland.

Distance: The running distance of Xletix is about 2km longer. Don’t underestimate this though because Xletix has also way more loose gravel and deep sand and steep slopes.

Obstacles: Xletix has more obstacles. I categorize obstacles roughly in three categories: Hardly noticable, medium and big.

The number of big obstacles, those that are really challenging and/or really fun is similar. Xletix’ highlight is a big water slide about 40m long and 20m high and amazingly fast. Tough Mudders highlight is a short slide into a pool of ice water. Refreshing! Xletics has a similar thing but with out the slide. You have to climb into the ice water, which makes it both harder and less fun in my opinion.

In the medium category Xletix has more obstacles and at least according to my impression more obstacles per/km. With these obstacles you have to climb over or crawl under something, but they are easy to tackle alone or maybe with a little push of your team mates.

I don’t care about the tiny obstacles but Xletix has more of those because the track had lots of crossings where one direction had to crawl under a tiny bridge while the other direction “climbs” over the bridge.

Organisation: The organisation is really similar at both events: Parking, Checkin, a place to store luggage but better nothing of high value, warm up, water and food on the track and cold showers afterwards.

The only difference I noticed was that there wasn’t enough food at the track, possibly because we started rather late and also certainly weren’t the fastest.

Summary: I enjoyed both events a lot, but Xletix was a little more challenging and fun. I’ll do both again, Tough Mudder in about a month and Xletix in a year.

If you are wondering how fit you have to be to participate and to finish such a race: Being able to run 10km somewhat comfortable in training should be sufficient assuming you are otherwise of good health.

And if you want to join a team in Northern Germany: let me know.

But recently I got the opportunity to do a talk for a company event and the company offered to pay me! Now that is great just for the ego boost alone. But it brings up a completely new question:

How much should I charge for a speaking gig?

Quick warning: you won’t find a Dollar or Euro amount in this article.

My situation is as so often the bright side of the problem. There are many in a less comfortable situation.

Maybe you want to get into public speaking but you don’t have the experience yet and nobody wants to pay for your expenses.

Or you are experienced but conference organizers still expect you to do your talk for free and pay for travel costs yourself.

This is how I try to think about this:

No matter if you get paid financially you are selling a service (giving a talk) to someone who wants that service, the conference organizer. You need to come up with a price that makes it worthwhile for you. This means: the price you charge is of higher value then your investment.

The organizer should also come up with a price they are willing to pay. The value of your talk to them shouldn’t be lower than what they pay for it. If their price is higher than your price you’ll be able to strike a deal where both sides profit. This is really the basic underlying principle of all commercial transactions.

In order to come up with the right price for your side of this calculation you need to consider your investments. This will consist of the following:

• Time: time to prepare and practice the talk. Time to travel. If traveling and speaking is stressful for you it might even include time to recover. How much time you need depends in turn on many things. How new is the talk for you? I have some talks where I literally spend 5 minutes to take a look at the slide before I’m ready to speak. If I have to prepare the slides I might spend dozen of hours to prepare examples and slides. If I where to give a TED talk, I’d probably would want to spend 100hrs just practicing. I’d love to give a talk about quantum computing but I’ll need to spend many hours to learn the stuff first myself. And of course we all know: It will always take longer than we first estimated.

• Material: Do you use give aways? Do you build physical stuff for demonstrating IOT? Do you use a notebook? These things will eventually break. So a part of their costs should be covered by the price of your talk.

• Pain/Joy: Do you enjoy doing the talk? If so that cost is actually negative or is it to be a painful experience? Then it has to be offset by appropriate payment.

The more interesting part is how much do you want to get paid for this?

There are typically the following types of payment involved:

• Exposure: Yes, I do consider exposure to be a totally valid form of payment. When I gave my now boss a call about three years ago he already knew me. Because I had a blog, because I was co organizing a JUG, possibly because I gave a couple of talks at conferences. That certainly turned out to be very valuable. The tricky part about exposure is that it’s value changes with your experience. If you are relatively new to public speaking and aren’t well known within your target audience exposure is extremely valueable, because it gives you access to more opportunities. But if you do multiple talks a month all over the world only very few organizers may offer you a relevant amount of exposure. Maybe TED can or maybe speaking in front of the NATO might qualify, but the average conference for your trade? Probably not so much.

• Access to the conference: Again this is often very valuable at the beginning of your career because you can learn a lot at conferences. But if you are at a conference every other month, you have seen all the talks, and there is very little value in most conferences. Which brings us to the final measure:

• Money: This basically has to cover everything that isn’t covered by the other options. What was helpful for me was to compare it to what I would do instead. One option is certainly my regular day job. If I do a talk on my own bill I’ll have to at least take a day off so the money I earn from the talk should probably be in the same ball park.

The calculation changes if you want to make speaking your main career. I probably won’t be able to give you much useful advice in that case but one number you probably should consider is: What amount of money do I have to earn so I won’t want to switch to another job instead.

So you end up with a price. The organizer hopefully does something similar. If your price is lower than the price of the organizer you strike a deal. If not you both might think again about your price if you are willing to move it a litte but if not the discussion is over.

The important part is that there is really no reason to be upset. Do you get angry if you see a market stand selling apples and you don’t want any? Of course not. Your current price for an apple happens to be lower then the price demanded by the seller. So you don’t buy. But if you get upset don’t demand the organizer has to pay you your price. Or as the organizer don’t demand that a speaker accepts only exposure as payment. By such a behaviour you just demonstrate that you don’t understand the very basics of commercial transaction. At least to me that would be highly embarrassing and I would try to avoid that at all cost. But hey the chances are it will give you some exposure on twitter or reddit and since you value that so high it might be actually a win for you.

In the previous one I described how to add a footer to your slides or actually put html code from AsciiDoc anywhere in the resulting HTML pages where you want or need it.

If I may remind you this piece of code in your AsciiDoc document creates some HTML for a footer:

++++
<div id="schauderhaft-footer" class="footer">
    <span class="element">#cool-talk</span>
    <span class="element">@some-conf</span>
    <span class="element">@jensschauder</span>
</div>
    
<script type="text/javascript">
    window.addEventListener("load", function() {
    
        revealDiv = document.querySelector("body div.reveal")
        footer = document.getElementById("schauderhaft-footer");
        revealDiv.appendChild(footer);
    
    } );
</script>
++++

But if you do many presentations you probably want a similar footer everywhere and change only a very small part of it: The hash tag for the event and the talk, while all the boiler plate stays the same.

The solution to this are includes and variables.

Includes are easy and obvious. They allow you to reference one document from the other in AsciiDoc and AsciiDoc will replace the reference with the content of the included file before processing it.

It looks like this:

include::footer.ad[]    

This will pretty much pretend the content of footer.ad is right there instead of the include statement. So you can hide all that ugly HTML in a separate file.

But I wanted to easily modify details of the footer. Variables are the answer.

At the beginning of my main document I have this:

:twitter-tag: @jensschauder
:conference-tag: @JUGNBG
:talk-tag: #sd-jdbc

This defines three variables and sets their respective values.

And the <div> in my footer.ad actually looks like this:

<div id="schauderhaft-footer" class="footer">
    <span class="element">{twitter-tag}</span>
    <span class="element">{conference-tag}</span>
    <span class="element">{talk-tag}</span>
</div>

So now you can easily set the content of your footer in your main document, without even looking at HTML anymore.

You are welcome.

On the other hand, I had the same option last year and very consciously decided not to submit a talk. So what changed?

I’d be happy if I could claim that the situation for democracy and human rights in the US improved. But that would be lying. The Trump-administration keeps flattering dictators. They fight against open and free media. They trample basic moral standards and openly push racism.

What changed is my standing within Pivotal. When I made the decision last year I just had started at Pivotal. I never thought that anything bad for me would come from my political opinion at Pivotal. But still, if you just got basically your dream job you don’t want everybody at your employer know you as “The guy who got sent back at the airport.”

And that changed slowly but surely during the last year. I met more of my coworkers, including some of the famous ones. I even talked to the CEO. And all the interactions turned the knowledge of security I had about a year ago into a feeling of security.

Today I have no problem tweeting my opinion about Trump. This recent exchange on twitter really catches my thoughts about this:

Me: “I think I finally got it. @realDonaldTrump is Ken M! It’s basically Andy Kaufman on steroids. Feeling much better now.”

Michael Simons: “Careful. Remember who wants to go to S1P. ;)”

Me: “If I speak at S1P I’ll be hardly noticed next to all these awesome and famous speakers. But if I write a blog article about how I was sent back home at the border I’ll reap so much exposure from that.”

Or to spell it out less tongue in cheek: I don’t think about what effects my tweets have on my chances to be allowed into the US. If I see something that I think people should hear my opinion about I’ll tweet it.

I do hope I’ll get allowed in and are actually confident I will. And if you are at Spring One let us meet. Especially if you disagree with my thoughts about Trump and are interested in an honest friendly discussion. I know it will be difficult for both of us but I’d like to understand. I won’t convince you and you won’t convince me, but if we understand each other just a little better we are moving in the right direction.

I really hate the footers in many slide templates. Often they contain information either nobody cares about at all, or if someone cares they shouldn’t be in the talk. Examples are the current date the number of slides and the title of the talk. Although I have to admit I once ended up in the wrong lecture at university and I would have loved a slide warning me about that because sitting in a bad economics lecture is really scary for a physicist in training. But that was at a time when slides where hand-drawn with chalk on a black board and dinosaurs roamed the earth.

But there are a couple of things I’d actually like to have on each and every slide:

• a twitter handle or hashtag for the event I’m presenting on
• a hashtag for the talk
• my own twitter handle

The idea being that this makes sharing content on social media easier.

So lets have a footer on each and every slide. Easy, right? Well, not really. At least with my setup and my non-existing knowledge of frontend technology.

The problem is that AsciiDoc puts whatever content you have in section tags in the generated HTML, but you really want something that breaks out of these tags in order to be relative to the full screen and also to be the same for all the slides. After some googling and experimenting it turns out, it is actually really easy. This is actually so easy, even I can do it using the following steps:

1. Have a section that is literally included in the output without any processing by AsciiDoc. You get those by putting the content between a pair of ++++

2. In that section have a div containing your footer content, with a nice unique id like so:

    ++++
    <div id="schauderhaft-footer" class="footer">
        <span class="element">#cool-talk</span>
        <span class="element">@some-conf</span>
        <span class="element">@jensschauder</span>
    </div>
    ++++
   

3. Add a tiny piece of javascript that moves the div to the location where you actually want it to be. The following script tag goes between the pair of ++++ as well:

    <script type="text/javascript">
        window.addEventListener("load", function() {
       
            revealDiv = document.querySelector("body div.reveal")
            footer = document.getElementById("schauderhaft-footer");
            revealDiv.appendChild(footer);
       
        } );
    </script>
   

4. Add styling to your sass template to make it look as you wish. These are the styling I use:

    .footer {
      position: absolute;
      display: table;
      width: 100%;
      bottom: 0;
       
      color: $color-primary-2;
    }
       
    .footer span {
      display: table-cell;
      padding: 0px 15px 5px;
       
      text-align: center;
      font-family: "Roboto Mono", monospace;
      font-size: 70%;
    }
       
    .footer span:nth-of-type(1) {
      text-align: left;
    }
    .footer span:nth-last-child(1) {
      text-align: right;
    }
   

Not that bad, isn’t it?

I’ll try to not let you wait for the next installment of my blog for that long.

But when I do slides they are mostly for talks. Even if I sometimes fail to make it show: A lot of time goes into these slides. And I try to give these talks multiple time. Which often left me with folders full of variations of a slide deck and no idea what the differences are.

So a couple of years ago I decided I have to find an alternative. And by now I’m somewhat happy with what I found and as usual, learned a lot about the tools I ended up using.

Here are my original goals:

Diffable: Everything should be text based so I can use git in a useful way.

Consistent look: I want a certain style for my slides and I don’t want to recreate that every time I create a new slide deck.

DRY (don’t repeat yourself): I want to reuse parts of slides like the “About Me” slide and the style.

Automated: Since the first point meant I was going for something text-based, the process to convert it into actual slides should be automated.

Include code from actual sources: About half of my talks are technical and might include traces of source code. I want this source code to come from actual source files that I can compile and test, so I can be reasonably sure that they actually work.

Reusable knowledge: I’d like to use technology that I can use in other contexts.

And this is what I came up with:

The first choice I made was Reveal.js. It is a JavaScript framework for creating slides. On its own, it lets you write HTML which then gets rendered as slides, with transitions and everything as one might expect. I used it quite some time as a standalone solution.

Since the slides are just HTML you can host them easily whereever you want, which for me means GitHub pages. And all you need to present them is either the files or an internet connection and a computer with a browser. But typing HTML is something for a bigger masochist than me.

After trying MarkDown which turned out not to be powerful enough for the stuff I wanted I ended up with AsciiDoc for authoring the slides. AsciiDoc is originally intended as an easy to write replacement for DocBook. DocBook is an XML format for documentation which can be converted into all kinds of formats. HTML and PDF are the most important ones I guess. AsciiDoc is used in many places to write documentation including the Spring documentation. It is also easy to write since it uses mostly plain Ascii characters for formatting, similar to MarkDown. It also allows to include source code either directly or as an include from other files, which fit my requirements really nicely. Same goes for partial documents so stuff you want to reuse in multiple places can be extracted in separate files. A good plus for DRY. Fortunately, there is a Reveal.js backend which creates Reveal.js slides from AsciiDoc documents.

I didn’t like the way the slides looked in Reveal.js by default. To some extent because I just wanted to have my own style. Not necessarily because my style is in any way better than the standard. Since Reveal.js is just HTML5 you can do that by writing CSS which I know almost nothing about. That’s what I call a good opportunity to learn. But Reveal.js doesn’t use CSS directly, it uses SASS instead which makes CSS more DRY.

Finally, I have to put everything together. Since I’m a Java guy I wanted to use one of the established build tools. I started with Gradle since that was what I preferred at the time because it is less verbose than Maven. But eventually, my slides were the only stuff left that was build with Gradle. And I really didn’t understand my own build file anymore. This was at least to some extent because I only worked with it sporadically. At the same time, I also learned more about how Maven actually works and with Spring Data I worked on a project that actually used AsciiDoc and processed it using Maven. So I switched to Maven for my slides as well.

So this is my tech stack for my slides:

• AsciiDoc for writing slides
• SASS for styling them
• Maven for converting them
• Reveal.js as the target format.
• Atom, IntelliJ, and Grammarly for editing
• Git for versions control
• GitHub for hosting the repositories and the final pages.

Making everything work was some serious work, and there are still things I want to improve. But by now I’m somewhat satisfied with what I got. I’ll write more about how everything works and what I learned along the way, but that are topics for future articles.

For now, you can take a look at a typical project on Github and the resulting slides.

You might think: The new API is based on Joda Time which is awesome. How can it be possible a mistake to use a class from this API?

The problem is that there is a very common use case when using the java.time API and at first LocalDateTime seems to be the right choice for this use case but it actually isn’t. The use case is this:

You want to represent a point in time without worrying about time zones.

Sure enough LocalDateTime doesn’t include any time zone information. So what is the problem? Let’s take a look at the documentation:

LocalDateTime is an immutable date-time object that represents a date-time, often viewed as year-month-day-hour-minute-second. […] This class does not store or represent a time-zone. Instead, it is a description of the date, as used for birthdays, combined with the local time as seen on a wall clock. It cannot represent an instant on the timeline without additional information such as an offset or time-zone.

Let me repeat the important part

[LocalDateTime] cannot represent an instant on the time-line without additional information.

If you invoke LocalDateTime.now() an hour apart before and after your default timezone turns the clocks back due to daylight savings time you’ll get two identical instances and you will have no way to tell them apart. Most likely this is not what you want in most use cases. And definitely not in the use case described above. What you want instead is Instant. Let’s look into its JavaDoc:

This class models a single instantaneous point on the timeline. This might be used to record event time-stamps in the application.

Just what you want.

This leaves the question: What is the use case for LocalDateTime? So far all examples I came up with had one thing in common: the LocalDateTime information comes from a different source than the time zone information and get combined to actually get a point in time. One example I came up with is sending out mass E-mails. You might want to control when people are getting the E-mails. Maybe you want them to arrive early during the workday or right after lunch. So you pick a LocalDateTime to represent that like “next Monday 8 am” or “Tuesday at 1 pm”. Then you can combine that with the time zone based on the physical location of the E-mail recipient to determine the right point in time to send the E-mail out.

I know, it’s a contrived example but that is my point: It is hard to come up with a valid and realistic use case for LocalDateTime. The next time you want to type that class name, think twice if this is really what you want.

I will do some Freeletics at 7 am near the pool of the Hotel Ling Bao. Oliver Milke will come too and others announced plans to join.

Freeletics is an app that lets you track High-Intensity Interval Trainings with your own body weight as resistance. This means:

• It is intense. You’ll be completely exhausted afterward. You will also be insanely proud of yourself for finishing the workout.

• It doesn’t take long. A workout is most of the time 20-30min + warm up and cool down.

• You can do it almost everywhere. In your garden, in a carport, in a park or as we are going to show at the pool in a hotel.

• It is a great cheap way to get fit.

If you want to join all you have to do is show up. If you never did Freeletics here are a couple things you might want to do/bring.

Do now:

• Download the app

• Register with the app

Bring on Tuesday:

• yourself, dressed in clothes that a comfortable and may get really sweaty. Also known as sports clothes. You’ll have those packed anyway for the community running event on Wednesday, right?

• something to drink. No, not cocktails. More like … water.

• your smartphone with the installed app.

• a towel

• possibly a thin gymnastic mat, but a towel will do.

Disclaimer: Just as with the rest of your life: Whatever you do you do it at your own risk.

My advice was and is: “Don’t”. Here is why.

Just for those that never discussed software development with me: I’m a huge fan of TDD. I think it is an essential skill. And assuming you want to work as a software developer, if you find yourself in a place where you are not encouraged to do TDD I encourage you to find a new job. The place you are currently at is most probably a dead end career wise.

So why shouldn’t you convince your coworkers to do TDD in order to fix quality problems? Two reasons:

1. It is a stereotypical example of “If you only have a hammer every problem looks like a nail.”

2. If you push a solution the chance that it will get rejected is really big. And that would be a sad state for such a powerful tool as TDD.

Instead of proposing your favorite tool to fix the problem, spend the time to find a solution together with the team. This starts by finding out if there is a problem. You might think there is a problem. Others might not.

I once was involved in a software release which was rejected after 1-2 days of testing by the customer as way too buggy and basically not fit for use. After the meeting in which the customer explained his opinion to us I drove home together with our test manager. The dialog went something like this:

Me: Wow, that was embarrassing!

TM: I don’t think so.

Me: But we delivered software that was rejected immediately by the customer!

TM: Not our problem. It’s his task to test the software.

Me: —

I still think the TM was failing at his job, badly. But that is not the point here. The point is that our opinions about if there is a problem differed widely. What you might experience as an embarrassment might be completely normal for the guy next to you. And vice versa!

Have an open discussion about what you percive as a quality problem

Maybe the others agree. If so you made a big step forward. If everybody acknowledges there is a problem it is much easier to convince people to do something about it.

If your opinions differ you have another discussion upcoming: How do you arrive to so different evaluations and what to do about it?

Let’s assume for now you agree on having a quality problem. Where does it come from? And what might be good measures to fix it or at least make it less sever?

TDD might be a solution. But there are many scenarios where it isn’t. Here are some I have seen in the past:

No version control system or one not up to the task. You might think everybody is using Git by now? Probably not. I’m sure there are tons of projects that use VSS, CVS, SVN, PVCS or just the occasional zip file.

Lack of skills Maybe there are team members that don’t have the required skills and just need training or coaching.

Lack of understanding what is expected I have seen developers that consider it sufficient when their code compiles and they know one example where it produces the correct result. The rest is the job of the test team.

Unclear requirements I once worked in a project where we needed 3 times as long es planned for a task. But not to actually implement it, but just to understand what is expected. Only then could we start with actual coding. I guess it doesn’t surprise anybody that the quality was abysmal.

In all these scenarios and in many others TDD is of no help.

But even when your quality problems are of the kind that could be improved by applying TDD there might be better alternatives. Have you tried code reviews? Is anybody testing the product at all? Manual tests, explorative or other wise are options that might help more in your current situation. Maybe integration tests can help more right now? Or how about pair programming? Or better monitoring in order to identify and therefor fix problems faster?

All these are valid tools to improve the quality of software. Which one is the right one depends on your situation.

If this is discussed in the team and agreement achieved that TDD sounds most promissing: Then do TDD. Your chances that it will actually help are now much better. Among others because the team won’t go “I told you that TDD shit is useless” on the first bug that gets passt the shiny unit tests.

When I started the new job there were many things I was looking forward to and they basically all worked out more or less as I expected:

Working with very smart people with a passion for software development.

Before I was used to being one of the most experienced developers in the team. That was great for the ego. It was also enjoyable because it gave me comparable big leverage on decisions made in the project. Now I’m the junior in many respects. Which is great because now I’m learning something every single day at work. Sometimes it is just small stuff, e.g. some shortcut or a smooth way for rebasing stuff. Sometimes it is project specific stuff like abstractions used inside Spring Data. But often it is the kind I like most: Features about programming languages and libraries. So far I was able to use Java 8 almost all the time sometimes even JDK 9. I learned about MyBatis, JOOQ, Querydsl, Lombok and many more. It’s just great. It is also rather challenging to see your coworkers being way faster than you are. More about that later.

Working with great hardware.

I spend a serious part of 2016 with my previous employer fighting to get reasonable hardware for my team and myself. It famously ended with the statement:

Ok you proved that faster machines are actually faster for the stuff you do all day. You still have to use the same machine we give to the secretaries.

Which is kind of funny considering that the whole thing started with the premise.

You don’t get more than a secretary, because I don’t believe your work will actually benefit from it.

Yeah, I know, pretty funny in hindsight.

Compare that to how things worked for me at Pivotal: I got two questions in order to decide which hardware I would get:

Do you prefere 15” or 13”?

and

What kind of keyboard layout do you want?

Because it was assumed that I would want an Apple Mac Book Pro and it was also assumed that I would get the (almost) fully loaded version. (It doesn’t have the largest SSD but I have plenty of space so that is fine.)

Working on a great project.

I guess not everybody is a Spring fan. That is fine. But I happen to be a fan since I used it for the first time. And it definitely has a huge user base. So I’m working on something that many people use every day, because they want to. When I was working on Enterprise software the user base was tiny most of the time. Sometimes even zero when the project died before the first release. And I never ever had a user play with what I build in her spare time in order to try all the new feature or even demoing it on a conference.

Just two days ago I was sitting in a hotel lobby listening in on people totally amazed by the latest features in Spring. I’m fully aware that my contribution to that is tiny. Still. That is a cool feeling!

And then there are the things that scared me a little. Or that I didn’t think about at all.

Working remote, alone, in my tiny home office.

Luckily this worked out great too. If you only know me from the internet and conferences you might not be aware of it but I’m a complete introvert. One effect of this is that I actually enjoy being alone. So that part is no problem at all. Not having to commute 45-90min one way is a great plus. Seeing my family much more obviously too. On the not so good side: I really miss pair programming. But a few weeks https://twitter.com/u/meistermeier[Gerrit] joined Neo4J and is working on their side of Spring Data, so there might be a chance for some pair programming.

In general the lack of social contact was a little scary, but again it worked out great. I make sure I meet plenty of people in my spare time so that is taken care of.

My office is tiny. It would probably be illegal to have so much stuff in a normal office in Germany. But it is all my stuff so while it might be horrible for others it is really comfortable for myself. I’m enjoying it a lot. Especially when I have some reading to do and can cuddle in the comfy chair I inherited from my dad.

Working in public with everyone watching you

Almost all my work result end up on public repositories on Github. Or at least in repositories that will be public eventually. So every typo, every stupid mistake is there for you to see and to make fun about it.

Some mistakes where found.

Fast. Did I mention the whole Spring stuff is popular? And Spring Data is used by many other Spring projects?

Turns out, if you break a snapshot build you learn about it within an hour.

Trust me. I tried it.

Shit like this happens. Time to remind yourself that making mistakes is an essential part of learning. I’m still trying to get used to it, but I’m making progress.

Working with no one watching you or telling you what to do

If you end up doing nothing, you’ll have a hard time coming up with something to tell on the next standup. Other than that nothing would happen. There are no coworkers glancing at your screen and wondering if playing jewels is an important part of your project. There isn’t even anybody looking at your hours. If you are living in an enterprise world you are probably used to

1. Writing down how long you worked.

2. Assigning your work time to different projects.

3. Getting complains if you assign to much time to a project

4. Having to enter that information in at least 2 systems, once for your employer and once for the customer (my personal record was 7 I think).

5. Having someone comparing the numbers from the different systems and complaining when they don’t match.

We have nothing of that. That feels weird after being used to the system above for almost 20 years. Interestingly it has the opposite effect of what one might expect, at least for me.

I’m really slow compared to my coworkers. Fast just isn’t my thing. And I’m (still) new, so I need more of the slow working than my coworkers need of their fast working. It made me feel really unproductive. Early on this tempted me to compensate by working extra hours.

But I know from past experience this makes me effectively even slower. So I put up my own Google Docs Sheet to track my hours, so I can be fair to Pivotal by working the hours I promised and also to myself and my family.

After some time getting used to it it feels great. And I actually work more concentrated than I used to, because now I’m getting paid for my work, while before I was essentially being paid for being in the office.

Managing interruptions

While I talk about productivity there is one thing that kind of caught me of guard. Pretty much everybody works remote on the Spring teams. So tools like Slack, Google Hangout, Skype, E-Mail and even Twitter are essential (in more or less that order).

I hardly used Slack before but now I wanted to have it open all the time so I see what people on my team are talking about.

Problem: Slack by default notifies you when something happens. Possibly worse: if you have an unread message it displays a big red dot on the icon when you use CMD-Tab to switch windows. This creates a strong urge to check what message that is.

Flow interrupted.

Not good.

After some configuration of notification settings nothing interrupts me anymore, except very few exceptions: mentions on slack, phone calls and SMS. Much better.

The enemies that I still have on that front are Twitter and long running tests which make it so tempting to check twitter.

So no drawback? All unicorns and stuff?

Of course not. There is always something to complain about.

As mentioned above, I’d like to do more pair programming.

I also find it slightly irritating that I don’t build complete projects anymore.

But this job is as close to perfect as I can realistically imagine. Actually it is way closer than I believed possible a year ago.

There is no way I’m going back. Not if I don’t have to.

So you are telling us all this just to make us jealous?

No. I don’t.

Ok, a little.

But also to tell you: Think about what you like and don’t like in your job. What is really important? Hint: if you are an experienced software developer it is most certainly not the money. Look for the perfect job for you.

Consider remote working. It opens up lots of opportunities.