Quick update: I’ll probably become available for consulting/contracting work again after the summer 2023.

(Most likely I’ll still be focused on web+backend with Typescript+Kotlin, which is the stack I’m currently using with my current client.)

Just setting up a new home at:

fosstodon.org/@thomanil

I’m taking some time off from client work to work on personal projects, update my skillset and recharge: I will become available for client work again roughly around Q4 this year. I am booked for my next client starting from october 1st. I may become available for new clients sometime in 2022.

I am available for consulting/contracting again in Q3 2020: get in touch!

EDIT: I am booked again, until Q1 2021. However: feel free to contact me if you want to discuss future possibilities!

I enjoy programming. Unfortunately, my skull is too small to hold a lot of stuff at the same time. Because of this, I have to keep my eyes on the target and I have to take small steps. If I don’t, I risk introducing bugs and unneccessary cruft. Perhaps you’re different, but this is how my head works.

A technique I sometimes use is pseudocode. I write my intended code out as simple sentences first, to see if it makes sense to me. If it doesn’t, I rewrite and edit more. When I’m happy with the story, I translate it into real code. Continue reading “Programmer Friday: I love pseudocode” →

We keep coming up with new ways to build software. Many of them are positives. Some of them are temporary setbacks. They are often new takes on things that have been tried before.

Sometimes it’s a joy to jump on that new framework, library or language. “Yes! Finally a better way of doing this!” 

But often, you’ll have a bad gut feeling. “This was a bad idea years ago”, or “that sounds like a dead end” or simply “I don’t want to do it this way!”

As you get more experienced, you are more likely to have this negative reaction when you encounter new technology. Is it justified? How do you know?

Continue reading “Programmer Friday: Careful conservative or grumpy grouch?” →

If you join a team I’m working at, you’ll probably hear this from me on your first day:

“…we’ve done our best to write documentation, but I know that it could be way better. Could you help out? It would be awesome if we could improve the docs together while you’re getting to know the project: that’s the best time for it!”

I’ve done this for years now — and no, it’s not because I don’t want to write documentation myself.
Continue reading “Programmer Friday: New here? Please help with the docs!” →

I won’t become available for consulting again for new clients until August 2019 at the earliest. But feel free to contact me if you just need some advice or want to discuss future possibilities!

A father and son is cooking ham. Every time they do this, the father cuts a chunk off each side of the ham before it goes into the pan.

The son asks why they perform this ritual. Dad responds: “I don’t know. Grandfather is a good cook and he always does this, so I just mimic him. I’m sure it improves the recipe in some way.”

The next time Grandfather visits, they ask him about that ham cutting routine.

“Son, grandson. I don’t do that anymore. The only reason I sliced bits off was to make the ham fit. My old cooking pan was too small.”

The daily standup ritual

We have rituals in software development as well. One of them is the daily standup meeting. Continue reading “Programmer Friday: Do you need daily standup meetings?” →

Some level of documentation is necessary in software projects.

We like to say that “the code should speak for itself” and “docs always get outdated anyway”. Both of these arguments are valid, but they should not be an excuse to drop documentation altogether.

Having some documentation in place both:

A) makes it easier to onboard new colleagues,

B) gives you checklists for critical tasks, and

C) makes it easier to get back up to speed again if you’ve been away from the project.

At a minimum, I expect to see the following points covered in Android README files:

Continue reading “Android Friday: Things I want to see in the README file” →