I have seen this book recommended for years by Silicon Valley moguls. Andy Grove wrote this book as he was the CEO of Intel at the most successful time of the company.

The book is holding a lot of substance, even if I disliked some of the lack of humanism.

Especially two points:

• that you should motivate your workforce by making them compete amongst each other (there is such an example where they give a score to cleaning teams, so that they start trying to beat each others’ score). This feels manipulative.
• some point about the fact that being nice is not the goal, that efficiency is the only goal. I am inclined not to believe that and feel that a company having such values is doomed to be a sad place (and ultimately, not very efficient). I hope that I am not wearing too rosy glasses.
  

Other than that, I found many other points interesting:

• that there is this idea that you promote incompetent people up to the first level where they are incompetent, and that it is a bad practice. Andy Grove makes the point that there is no way out of this. If you are promoting incompetent people instead, you are just sending a bad message to the organisation.
• There is an interesting section about interviewing. It says that it should be relatively free form, but also that there is no magic trick. It is a hard process and mistakes happen there. The conversation should not be adversarial, but open. This part is hard to summarise because there are too much good ideas, actually. Read it.
• Manager should be the teachers of their organisation: they have two levers for managing, motivating people and teaching them. The second lever is insufficiently used.
• Meetings are not evil, they are one of the tools to transfer information. Obviously, that does not mean that too much meetings are not bad or that meetings should not be well organised.
  
• That dual reporting is the normal way in larger organisations: there should be at least a layer of the organisation that reports both to mission oriented people (the salesforce, for example) and to tech oriented people (to share information and resources amongst pairs). Anything that does only one of these reporting will be either inefficient (think a sales team hiring its tech team alone) or too detached from reality (think a tech team barely speaking to a sales team. This is often called working in silos).

All in all, a good, interesting read. I felt sometimes that it could have been shorter, but the information ratio is still quite good in my opinion.

When you already know four js frontend frameworks (and two are still somewhat up to date).
When you know Django but not Ruby on Rails.
When you know Java but not .net.
Basically, when you know one way that works well but not yet the other one.

There is not much point in learning the other way.

You should rather try to learn something else, that will help you achieve more, not achieve the same things in a different fashion.

IT Life

School parent online groups that I have seen can be filled with a lot of aggressivity towards teachers. I find it sad, and makes a point of asking questions like: “Did you talk with the teacher?” It is often not the case.

What I find sad is the tone of defiance often seen there. Lots of parents are distrustful of the school they put their kids in, while I doubt that you can choose education as a career out of anything but good intentions. It can not be for the money, that is for sure in Belgium.

Sure there exists bad teachers, but my opinion is that there also exist a lot of badly managed relationships from parents to teachers. That pushes me to try to be as encourageing as possible to teachers, so that they do not hear only about the complaints.

Finally, as a more general point, I also noted that if you voice a positive opinion in an online group, you usually open the door to other people who were not daring to go against the bad mood. There is often a silent satisfied group, and showing that it exists is important.

Ookla’s speedtest.net has been the go-to tool to test your network speed for years. They make money by showing you ads next to your speed test.

Google just completely copied their (admittedly simple) product, and put their tool on top of the the search results when you search for speedtest , which makes it appear just above Ookla.

I can not get over the feeling that this is wrong. Google being both a search engine and a tool/content provider leads to this kind of situation where they can cripple existing businesses, and prevent newcomers to compete.

Video game music is the best music to work for me. It’s usually just made to accompany the action, which is exactly what I need. Indie games also have the best electro tunes.

So, favorite soundtracks:

• Celeste
• Katana Zero
• Dead Cells
• Hotline Miami
• Sword and Sorcery
• Nuclear Throne
• Furi
• Journey
• Risk of Rain
• Duet (That one)

All these games are pretty cool to play too :-) Here is a sample playlist: open.spotify.com/playlist/…

Took some time to arrive, but I definitely love it, especially because I can carry any of my kids (including my 12 years old daughters) on the back rack. This avoids a lot of use of our car, for example for trips to the various activities: swimming pool, circus lesson, Taekwondo, …

see it here

I as there for a mission for Bluesquare in the context of the project about Sleeping Sickness that we are doing. More information in this Guardian article

Near La Bresse, Les Voges, France. Love that place.

No, but seriously. #claimtheclimate #climatechange #bruxelles #brussels #brussel

I made an iPad game. I then made it work on iPhone too. It took me 5 years to finish. I liked it. People who played said they liked it, but it only reached a tiny audience even if I did some paid advertising and used all the traffic of populationpyramid.net to promote it.

Now, it’s not on the App Store anymore, because it did not make sense to pay an Apple account for less than 10 downloads/year and the notch of the new iPhones felt like too much pain to handle for a symmetrical gameplay like this. 🤷🏻‍♂️

In software engineering, remote working makes a lot of sense since, most of the time, you only need a computer and an internet connection to perform your duties. So there are less reasons to force people to sit in a predefined office everyday. Consequently, it has become an important feature of a lot of IT jobs, even in Belgium, while it is definitely not the most forward looking job market. That said, most of the time, the remote working offer only apply to a part of the week (1 or 2 days a week seems to be the most frequent proposition here). Nevertheless, it definitely is getting a hold in most companies.

There is a lot of good to say about remote working, and I see a lot of rabid defence of the practice. I agree with most of it. That said, I have been working remotely for a little more than 5 years now, and I now must acknowledge that it does not come without stress. This might come as a surprise for some, but in the end, I think that remote working has taken some toll on me over the last two years, especially when I went almost fully remote for a year, from June 2016 to June 2017.

So, what can make remote working stressful?

Dehumanisation

If you are working remotely, communication tends to stick to structured channels: the chats, the daily standup, maybe a few global meeting (retrospective, company status) every other week, Jira for the tasks and bug reports and lots and lots of emails. This works well to accomplish structured tasks, but you might definitely feel disconnected from the company sometimes. The fact that most of this communication happens in written form, or in front of groups makes them unsuitable for small talk or more informal information. This can hamper your work, as just chatting about the atmosphere at work can deliver very important information about the smooth progress of projects, but most importantly, it can prevent you to feel as part of a community.

Also, written exchanges are more prone to misinterpretation, even with people you know very well. Not to mention that, if you already spend your day typing on a keyboard to accomplish your technical programming tasks, it might become annoying to have your communication done in written form too: you might end up feeling like a text processing machine.

So, after some time working remotely, it happened multiple times to me to miss the coffee chats, previously felt as unproductive wastes of time. I felt detached from the team, especially when the teams I worked with were made of multiple people working in the same office/place, and seeming to have fun.

Interruptions and multitasking

When working remotely as a developer, the chat (usually Slack or Hipchat) quickly becomes your lifeline to the company: that is the way most people will try to contact you. And to me, being responsive on the chat accomplishes the same as being on time at work in an office: it gives an image of reliability. It also implies that if you do not really want to give the impression that you are taking a lot of breaks, you might find yourself checking your notifications a lot while taking lunch for example, while if people had seen you working the whole morning, or if you were just talking with colleagues at that point, you would not feel the need to be so responsive. I actually often realized that other colleagues working remotely were criticized because they were not answering very quickly on the chat.

A part of the problem is that on a chat, people do not see you physically, so they cannot really estimate if you are at a good moment to be interrupted. So, you are interrupted a lot, and if you are a bit like me, you feel forced to answer quickly. So, you interrupt your work a lot. And in case you do not know it: interruptions are loathed by programmers, since it is really bad for their productivity as it breaks their focus.

The other problem with this remote chat setup is that people do not know if you are already speaking with somebody else. I cannot count the number of times where I have been juggling three different conversations at the same time, which, to me, can become stressful, especially when I do have tasks to finish by the end of the day.

Also, I must mention that there are also often “leisure” chats, created to host non-work stuff (usually, a lot of memes) that can become very, very chatty. At least, I feel that it is really sane to mute these chats most of the time, but when you come back, catching on everything that was said can be a daunting task, while it might be your only opportunity to have some “office spirit” that you are missing by being a remote worker.

Overworking

There are two types of obligations you get when you are taking a job:

Obligations of results, where you commit to give a certain result by a given date. Typically, for a developer, accomplishing a sprint with a given set of bugs/features to develop.

Obligations of means, where you mainly commit to spend some of your time everyday on your work, and you just give the results you managed to produce over that time.

I am not naive, and I know that in the end, in software engineering, most jobs are really about results (you will get fired in the end if you produce nothing), and not means, but in remote working, since people are not seeing you work, you might feel more obliged to show results everyday, even if it forces you to work way past 8 hours a day. As an example, I cannot count the number of times where a configuration problem or a customer call took me a few hours of my day, but I still felt forced to finish the task I committed to do on that day, so that nobody could assume that I was slacking off instead of working. I feel that if people had seen me in front of my computer all day, I would have felt more relaxed about deciding to finish the task the next days.

This leads to two things for me: being really appreciated for the reliability of my output, and … being seriously overworked. According to Jason Fried from Basecamp, this is the true challenge of managing remote workers: people who work too hard.

In the end, this all amounts for me to the question of trust: your employer trusted you a lot, allowing you to work on your own terms , and in exchange, I have always felt compelled to actually work a lot more than if I was in an office.

Being a stay at home dad

When you spend a good part of your time at home, your family sees you as more available than they should. Even if you have places dedicated to work that should be forbidden to your kids, it is still tempting to come ask you “just a little something”. Especially for kids, it is hard to compartimentalize their home. Actually, it is hard for me too …

This can make video calls a bit stressing, when you are talking with a customer for example, and your kids end up just appearing behind you on video. Here is the most well known example of this:

Farewell 2017. Thank you for giving us this. 😂 pic.twitter.com/tIUAzNnIUU

— BBC (@BBC) December 31, 2017

I also know some people have problems resisting the need to perform home duties, like cleaning the kitchen, for example. This has never been too much an issue for me, but on the other hand, this created tension with my wife from time to time, since it was difficult for her to understand how I could have left a dirty dish the whole day on the dining room table while I was actually at home. Answer: I was working and avoiding interruptions…

Loneliness.

Working at home can mean a lot of loneliness. I do enjoy being alone quite a lot, but even for me, after two weeks of only seeing colleagues through my screen, and then my family at night, I end up feeling quite sad. I miss feeling integrated in a community of pairs.

Social networks might help you fight that loneliness a little, but on the other hand, pausing only with social networks is not different enough physically from working on your computer. Moreover, it is also well known that spending more time on social networks rather tends to make you less happy than the opposite.

In the end, I really started to hate being alone most of the time and have felt it to be quite bad for my mental health and my mood. This is a well documented phenomenon.

One of the most recommended way to fight this is to work in coworking spaces. To me, they are a mixed bag: they cost some good money (that your employer might agree to pay, or not), and often ask for commitment (you usually need to register for at least a month). They can create social link (and for me, they created a lot of work opportunity, especially the Betacowork), but at the risk of feeling a bit too much like a vacation camp, with activities everyday (cooking, massages, meet ups, …), to force people to socialise.

Notice that I have been to coworking spaces where there was no socialisation, and gave up rather quickly, since it seemed rather pointless to go somewhere to avoid loneliness, and then not talk to anybody all day. So, I am ambiguous on the subject of forced socialisation.

Another problem with coworking spaces is that you might introduce long commute times in your life again, then work with headphones all day to avoid being distracted, barely taking a break because you lost time commuting, and feeling awkward for not having spoken with anybody while being there for the community. Not to mention that video calls are more difficult to do in these settings, since you usually lack a place to be alone, there is always a bit of noise, and people might be annoyed by your call. Moreover, sometimes, there are things that you do not want to say in front of strangers…

Stress to decide where you work everyday.

This might be just me, but not knowing where I will be working everyday, and having to think about which hardware I need to take with me (example: keyboards, DVI adapters, chargers) has led to a lot of problems, by removing the predictability of being all the time in the same office.

Also, notice that I think that working in coffee shops is a bad idea, at least for full days. There is usually too much noise, and I do not like feeling obligated to take something to eat/drink every hour (your mileage may vary), and the chairs are bad for your back…

You never leave “work”.

When you work remotely, you do not leave your working place at night. On top of that, if you work with people in different timezones, you might end up communicating a lot with people while your day is already over (I did that for months when working with people based in New York or SF). It often makes a lot of sense, since otherwise, you might have too few time to communicate with your team, and this can really hamper the progress of a project, but it means that there is no time in the day free of working concerns, which again, is bad for your mental health over the long run.

Also, working at home does not leave you time to cool off while coming back home from work. For me, the ideal duration of a commute is 15 to 20 minutes. That leaves you some time to walk, and so, do at least a bit of physical exercise, and to change your thoughts a little bit. There were a lot of evenings where I ended up going from a video meeting to a family dinner in 30 seconds, and I must says that it is not always easy to give a good attention to my kids in such occasions.

Career risk

Working remotely makes you less visible in your company. If you intend to have more responsibility in your job over time, this can end up being a problem. I worked for example for a company where I felt that people “in the office” were preferred for promotions. So, you have to consider that too when working remotely.

On a more humorous note, you have to consider than working in your sweat pants for years, unshaved and without too much time constraints might make you unfit to go back to work in an office. You might suffer from some degradation of your social skills:

See the whole comic about working at home here: http://theoatmeal.com/comics/working_home

Conclusion

Globally, I have enjoyed working remotely over the last few years, and it has been a boon to my family and my wife while my kids were small. I do think it made possible for my wife and me to pursue our careers without too much hassle, as I was more available to take care of the kids when they were sick, which happens a lot in the infancy years. This flexibility came to me at the price of catching up on work in the evenings and weekends, but it was still very much appreciated.

Remote working also allowed me to join teams of great quality that I would not have found in my local job market and to work on ambitious projects. So, all in all, I am still a great fan.

On the other hand, after more than 5 years of remote working, I have to say that it really took a toll on my mental comfort sometimes, and that had some unwanted impact on my family relationships, mainly irritability on my side. Before you experience it, it might seem as the perfect solution for your life, but as I tried to explain, there are a lots of unforeseen ways in which it can create stress.

To summarize, the main problem for me is to feel like a text processing machine, receiving mails, Jira tickets and chat messages as input and writing code as output, without the human interactions needed to make it more meaningful. I do not like becoming a kind of a remote developer black box.

#BXLdemandscleanair

I like taking pictures of tramways 🚋. ¯_(ツ)_/¯ #bruxelles #tramway #visitbrussels #brussels #brussel #ixelles

You will very rarely hear me say that something is a “must-read”, because I hate the phrase, but this is it.

A test of the waterlogue app. Lovely.

1, Infinite Loop.

I have been working on the iOS platform for two years now. I really enjoy it. I like the focus on fluidity and good user experience championed by Apple but I also like the engineering challenges that programming apps offers. Here is a whirlwind tour of what difficulties you could expect when beginning to program on iOS.

Fluidity

The first constraint that you have to take into account is this famous focus on fluidity. As I once saw on Twitter, the rule is "60fps or GTFO" (I think this was from @flyosity). Apple has set a standard of smoothness through all their apps (OK, almost all). The scrolling speed and responsiveness of the iOS platform is still globally a notch above everything else. This is seen as a given and you will see most of your users tap impatiently on their device if your app freezes more than half a second. And freezing while scrolling will most probably decrease your average number of stars on the app store.

Concurrency

To get fluidity, the recipe is well known: there is one main thread in charge of updating the UI of your apps. You just need to avoid doing input/output (disk or network) and expensive computations on this thread that would cause UI freezes.

Put differently, you have to make your program concurrent: launching the expensive tasks in background and waiting for them to callback. Problem: concurrency is hard, PhD thesis level hard. It is very difficult to think about a concurrent program because you lose the strict sequentiality, and you can easily get in troubles when modifying the same memory space through different threads.

The main problem here is that if you forget to go back to the main thread to update your UI at some point, you will experience crashes in your app (because UIKit, the graphical framework of Apple, is not thread-safe), but as always with concurrency, these crashes might not always happen, and be hard to reproduce in the debugging environment, because setting a breakpoint for example will change the sequence of events.

The matter is further complicated by the fact that if you use Core Data (and if you need structured data storage, this is the way), it brings its own constraints. Basically, you cannot manipulate a ManagedObject (the base data class of Core Data) on another thread than the one where it was created without risks of crashes. Happily, iOS offers some nice ways of distributing your work over multiple threads, but this brings me to the next difficulty of the iOS platform.

More than one way to do it

The Perl motto applies very well to iOS: "There's more than one way to do it". The technologies used in iOS date back to NeXTSTEP in 1989 and it shows, because you still find in the libraries the traces of this long history, with lots of variations in the way to do things over time. You often find very similar implementations of the same concepts, one in Objective-C and the other in a pure C API (UIFont vs CTFont, for example), with naturally some discrepancies. To get back to threads for example, you have at least 4 different ways to launch a task on a background thread:

1. using NSObject's performSelectorInBackground:withObject:
2. using NSThread
3. using the Grand Central Dispatch C API
4. using NSOperation introduced in iOS4

How do you know which one you should use? As a rule of thumb, you should use the highest level of abstraction that suits your needs, but this brings us to the next difficulty of iOS.

The doc

You will have to navigate the docs to find out which way is the right one in your case. Unfortunately, Apple's documentation is not easy for the beginners. As I read somewhere that I cannot find back now: the documentation is quite clear once you have understood the subject matter, meaning that everything is explained, but not always in the most straightforward manner, and sometimes, information is hidden in suprising spots. Notably, when lost, you should hunt first example Xcode projects provided by Apple to illustrate the use of some APIs, but beware, some of them are seriously outdated, and then you should look at WWWDC videos. Honestly, it was quite infurating for me to discover that some information is only available in video format (about Core Data contexts merging for example) which is obviously not very googlable (especially since this material is in fact behind a login wall).

Network

Another thing that makes iOS programming difficult is that you cannot count on stable network connections (but this applies to all mobile platforms, obviously). Every network request can fail due to the user movement. This is quite different from what happens when you do front end development or server development, where most connections are quite stable. You have to provide graceful behaviours for so much more types of problems.

What makes this even more important is that, compared to web apps, where users have been long taught to do a refresh when something seems to freeze, on mobile, users are not used to relaunch their apps in case of problems (and happily so). If your app is stuck in a bad state with no way for the user to get back in a better situation, there is a good chance that he will simply uninstall the app.

Other difficulties arise when you need to offer some functionalities offline (think about people using your app on the plane). This brings synchronization problems, that as a general rule, are as hard as concurrency problems. Nothing strictly related to iOS, but still a major cause of headaches.

Resources

Constrained resources must be cited too as difficulties. Over 70MB of RAM, your app will probably be killed by the system (but not for sure, it depends on other processes and the memory available on the device). Lots of javascript web apps consume more than that these days! Aside of memory, CPU is not that powerful, a lot less than your laptop computer obviously. This has to be taken into account too.

Memory management used to be a major pain point in objective-c, but it has gotten a lot better since the introduction of automatic reference counting in 2011. You still have to understand what will be kept in memory (everything for which your keep a strong pointer), and you will probably have to understand at some point how ARC behaves when using blocks, but over is the time where you spent hours chasing the superfluous release in your app.

Fighting the system

The degree of liberty offered in iOS to developers is way smaller than what is offered on Android. For example, you are not allowed to keep a daemon running in background when your app is minimized (to download files for example). If you have something like that to do, you have at most 10 minutes to execute them after the user minimized your app. Similarly, you are not allowed to keep a connection open to a server passively either, unless you are a VOIP app. There are also constraints to access the address book of users, keeping the GPS active, and so on, and so forth.

Most of these constraints stems from Apple's intent to keep the user experience pristine from bad developers experimentations, but that does not mean that these constraints cannot be frustrating and that finding workarounds is easy.

App Layout and Text manipulation

There is nothing similar to the flowing layout of HTML in iOS. If you want for example a UI with a paragraph of text and a button just underneath, you will have to compute the height of the text, and put the button at the right place. This can seem particulary brutal for web developers, and be hard to explain to customers and managers accustomed to the relative plasticity of html and css.

Furthermore, this may not apply to all types of apps, but if you need pixel perfect text manipulation, like I did for checkthis, you are in for lots of troubles. Either you have text editing using UITextview but without too much control on things like line height and stylings used for links, either, you have the full control offered by CoreText but without any editing capacities. You have to program all editing by yourself. I must say that there is hope on this front, with this (paying) component, but I did not test it. If you do not need text edition, but just more control over the layout and styling, you can use TTTAttributedLabel.

For layouting text, lots of people resort to HTML and CSS in UIWebView but this can get a bit unholy and offers challenge on its own due to the asynchronous rendering of webviews. I will not dive too much into the controversy of Native vs Web Apps, but let me just state that most popular apps on the App Store are mainly native.

Closed source

This might be obvious to some, but the fact that you cannot access the sources of the UIKit framework, or other important parts of the iOS platform can turn into a real problem when you hit a hard to understand bug. I lost count of the number of time I read on Twitter something along the lines of : "Apple's component x does not do expected behaviour Y, please give me back the days lost trying to understand." and I have been a victim numerous times too. The platform is not especially buggy, but not having access to the source complexifies debugging when needed.

As a side note, the quality of iOS open source varies wildly and there are big surprising holes that are not covered, like for example having a good Twitter connection library that would take into account the latest additions of the Social Framework, while fallbacking to classic in-browser-oauth when on iOS4-5 or when the user did not setup his accounts. I am not complaining about anyone's work here, just observing.

Conclusion

In conclusion, iOS is at the same time one of the most rewarding and challenging platform that I had to work with. There are lots of constraints to take into account but happily, I find the tooling extremely good. Instruments and Xcode are first rate tools. They obviously have their own quirks, but compared to Eclipse or Visual Studio, they fare very well.

On the rewarding side, Apple's customers are using tons of apps that they will take wherever they go, and this is the most personnal computing that I know of. Furthermore, there is a lot of demand for competent mobile developers these days and mobile is where the double digit growth is. So, if you are on the fence, I would encourage you to take the plunge into iOS development.

A gift for my sister in law. She’s a shrink. This thing makes me giddy.