In software engineering, we can apply a lot of the psychology findings to their digital counter part. If we consider the broken window theory, it doesn't apply to the operating system, but to the state of code.

Let's go back to the source. From an article originating from 1982 ("Broken Windows") in The Atlantic by James Wilson and George Kelling.

Tech job interviews. They are a very important part of the continuity of an organisation and the trajectory can wildly vary per company. I want to highlight a couple of tips for both interviewer as interviewee, from my perspective as having done both on several occasions.

Let's take a look at the companies' perspective. I think this perspective hold most value for both parties. Usually we can break down the interview process in a couple of steps, which boils down to the following phases:

As a hobby photographer, I upload some of my photos to a selling service called "Werk aan de Muur". It allows consumers to order prints while offloading the logistics to the service in exchange for a commission per print.

As software developer, I believe you should be able to own your own content. Which is one of the reasons I also launched this website.

As a mentor via CodingCoach.io I'm currently working my way through the 21 Days of Code coding challenge by Lighthouse Labs with my mentees. I thought to share our findings and resolutions here, as well as offer some perspective on these events.

Firstly, I kind of like this iteration (we've previously did a similar coding challenge side by side). We're following a storyline involving the Mayor of Codeville and face different kinds of challenges. It's nice to have some context and not simply solving problems. I think this is a really engaging way of keeping interest and motivation.

With the right processes and tooling, it becomes a lot easier to share code between developers. With the right amount of documentation in the right place, you also flatten the learning curve for onboarding developers to get up to speed. This reduces the risk that responsibility lies with a single developer (read: a single point of failure) and encourages developers to share, contribute, review and refactor code. Just make sure you have ample coverage so that you confidently can refactor, with minimal impact on existing features.

Any software project tends to grow in complexity over time. Without a good development strategy, sooner of later the quality of projects can erode.

What’s your best advice on how to make an impact?

This tweet from Una Kravets got me thinking: how do you make an impact?

Software development has such a high velocity compared to other industries because ideas and concepts can be shared so efficiently. I think the best description is the expression: “Standing on the shoulders of giants”: Make smart use of the work of your predecessors and colleagues. Use that also when acquiring knowledge: you don't have to do everything yourself. The development community is very large and helpful and a lot of information is easily accessible.

If anything was indicative of the frontend community in 2016, it was the term JavaScript Fatigue. What does it mean? The number of JavaScript frameworks has exploded over the past period. Indeed, it is an overwhelming number of new methods, tools and techniques available to us as developers. What can you do to keep your head above water or even take advantage of these rapid developments?

Siri, Cortana, Google Home, SlackBot, the Star Trek computer and in lesser extent K.I.T.T. These are all interfaces without an actual ‘face’. The Internet of Things connecting personal assistants such as Echo, Jibo or Zenbo with your home. I tend to call them assistants and not bots. I believe there is a nuance, where bots are more suited to perform the same repetitive task over and over again and assistants are more orientated towards user interaction with changing context and tasks.

Everything is connected: machine to machine, human to machine and vice versa.