Category Archives: Productivity

Time: Fail fast and bounce back

Reading Time: 2 minutes

Time saving tube fail

Nowadays, most tools we use exists to save time. In London to travel through public transports we have tons of options to make our lives easier. Contactless debit card, ticket, Oyster card, you name it. However, having the choice between these options may reveal troublesome when in a rush. Indeed, on Monday I used my debit card by accident instead of my Oyster card making myself pay for a right I already have. Also, if I did not use it again while leaving the tube I would have ended up getting charged the max amount. I think it is £6.60 instead of £2.40 for a journey in zone 1. Luckily, I realised my mistake on the spot allowing me to rectify it while leaving at my station.

I did that mistake because I saw the elevator open and jumped in. Yes I got in the elevator, but instead of losing a couple minutes I lost money. Indeed the amount is as insignificant as the time saved, however that got me thinking. I started thinking about these times where I made design or coding decisions to save time. The classic “let’s do something quick” that is basically the coder’s “spray and pray”.

Spray and pray then spray to slay

In Monday’s instance, the “spray and pray” was to tap my wallet on whichever side is more accessible. I knew odds to mistakenly use my debit card was 50/50 and I knew how to limit the loss in case of failure. When the failure happened, I paid a price I was ready for when the time came. Similarly to a project however, you need to reduce the risks of your decisions as much as possible or at least figure a way to turn things around if they go south. Failing to recognise the risks of the choices we make will be as punishing as the risks taken allow.

This might be the key here. Maybe, it’s not about missing a shot, but about the rebound. About what you will do when the ball bounces back. If you know how to bounce back from a mistake you will feel empowered to do more and learn from them. Maybe in the end being a good developer is not necessarily about making the right choice every time. It can be about evaluating the potential consequences of our choices and ensure that they are worth taking. Also it can be about whether we can adapt off the result of our choices.

So next time I take the tube, I will slow down to tap my Oyster instead of my debit card. Coding wise, I could run into the most MacGuffinest MacGuffin piece of software that might help on a project and still take time to evaluate its pros and cons so that I can mitigate the risks of using it.

My Musketeers for DotNet Test driven development

Simple continuous integration with Appveyor and Newman

1 Reply

Reading Time: 13 minutes

Last month, I posted about Postman enabling you to test your APIs with little effort so that you can build future-proof software. Here we are going to cover setting up continuous integration for a simple project by using Newman to run your Postman collections. You may have heard about continuous integration in the past. Most commonly, continuous integration will build software from one’s changes before or after merging them into the main codebase. Even though there is an infinity of tools that allow implementing continuous integration, I will focus on Appveyor CI. In order to make things simple, I will create a very basic web API project and will host it on GitHub.

Continue reading →

Going full necromancian on old projects

Leave a Reply

Reading Time: 2 minutes

Old projects, they often end in what I call development hell. This odd place where some projects with a good potential become stale after a release or die because too late for a market. Very often personal projects end up there even when they are open source. Open source really seem like a tool to help spreading and sharing knowledge worldwide depending on the kind of project. Before open source democratized with the likes of Github a huge number of personal projects probably took years to be released when not abandoned.

Today I decided to do the only kind of necromancy one should do: Bringing back an old project to life. A project for which I already wrote the code for the model and business logic. I had to make create a user interface and build a user experience as sleek as possible. However, I stopped it due to my vision of a market I thought crowded along with the lack of time. Now I see clearly that was not as true as I thought.

Here we are. Two months I did not post here, eleven months without working on a personal development project I am back at it. I spent my past weekends alternating between gym, party and sleep. Luckily, I work in a position where my brain I can keep my brain stimulated. Indeed, when not investigating an issue on one of our live apps nor working on our platform features I am defining development tools and processes to be used at company scale within the next months. Eventually, a lot of cool things will come out of that. I will definitely post a few related tutorials depending on schedule.

About the blog, I will try to post more regularly than I have maybe a tutorial. In terms of work I would like to share with you the video that we recorded last week. It is basically the new company careers video that I like not just because I am in it. You can definitely check it out below:

If you arrived that far in the post, first I would like to thank you for reading and watching the video. Second, do not abandon your old projects if you are not a 100% sure they are dead. Check your old source code even if it is to mock your old coding style. In the end you could actually have something worth the hassle.

Everybody wants to be right, worth it ?

Leave a Reply

Reading Time: 3 minutes

Be right or “be right”, getting the truth on your side or winning an argument ? We find people doing both in many domains, both in science and everyday’s life. When you are lawyer, winning an argument is the end game. For some time I wanted to be one which explains why I have been like that for a while when younger. I listened to people mostly to crush their arguments because it feels good to be right. Even though the intention was not glorious, I became a pretty good listener. It allowed me to be a bit more aware of my surroundings and pay more attention to people and their opinion as they can help my reflexion going forward.

Over time this dragged me into looking more for the truth rather than for a truth that would suit me. Actually, it made me closer the scientific mindset built during studies and allowed me to be a little more objective. Constantly trying to be right instead of searching for the truth never served science. However, objectivity allows to think better as the focus is on facts and not emotions.

I ran into that TED talk with Julia Galef about trying to be right even when wrong to win. I found it really interesting mostly because I used to have that soldier mindset at some point. Even though going through scientific studies and cultivating myself as much as possible I probably have a bit left. Grabbing a theory and trying to prove it true is not a bad thing as Science progresses from research. But it becomes terrible if you keep hanging on it even when proved wrong. Indeed, you may find reasons to keep your theory breathing but it will not make it less wrong.

I will let you have a look at the video first as she talks about it way better than I can then go back to how this can apply to Computer science.

Scout mindset. If you skipped the video, you should go back to it to figure that out. If you do not want to check it out for whatever reason, the scout mindset is what sets you to look after the truth rather than being right. Yearn for facts and proofs rather than feelings and spoofs (I am not looking at the Brexit voters at all). History taught us that being too much in that soldier mindset that she describes can be extremely damaging. Many exemples exist around the world, Nazis, Ukip, Turkey now ? But let us go back to why you are here, Computer science.

In IT the main domain where that scout mindset will be of use is basically any aspect of software development. Wether it is about picking a working methodology, building a new feature or simply bug fixing. The main issue when you build something is that you will naturally be more defensive about it wether you did good or not. And it is very hard when developing something on his own to detect flaws otherwise you have not written that code in the first place. As a way of going through that we have pair programming which works mostly when the collaborators have opposed views. You can also discuss with tech people among your friends and acquaintances as they may provide you a fresher view. Discussing with colleagues during a standup meeting or during a coffee break can help you to open your mind a little more.

I feel like I have been confusing in this article so I will try to sum up a bit. There is a couple of things to retain actually. First, yearn for facts, clues as it is what makes research progress in any domain. Second, to listen to people. Not just hearing them, but paying attention to the input they can provide even if you do not agree. Often people that you would usually ignore because you think you are better than them or whatever. Listening will save you time or open your mind with their knowledge, a knowledge you may not have. Being able to find a solution that makes you being right feels good, even if it is not the best one. Being right is like victory, it always feels good but it does not necessarily make you progress.

I hope you enjoyed the article, for more food for thought I recommend you to check out the TED Talks which contain a lot of interesting topics about everything. I personally focus on Technology, Society and Science subjects but there is a lot more than that. Who knows, maybe some day you will see me in one of those videos. On those words, have a nice evening, day, weekend or whatever this is to you. And oh yeah, get a free meme.