Although offices are almost always legally owned by a company, making the employees feel ownership comes with a lot of benefits.

If employees feel at home in the office they are more likely to share ideas and less likely to hold back constructive critisism (hide their candor), both of which are vital for the quality of the work delivered by the company.

To the employee, workspace ownership makes the difference between working for the company and being (part of) the company.

Decorating

This is the most obvious way of feeling ownership, and probably also the easiest. When people bring personal items and items with sentimental value, the office starts feeling comfortable.

This doesn’t stop at a picture of the kids and a drawing. Encourage employees to decorate the walls, buy funny mugs (or GitHub beer glasses), and so on.

If it feels like initiative and creativity is encouraged in the...

“Dialogues are a powerful tool,” he said, looking me dead in the eye, challenging me to disagree. “They allow for ideas to be expressed in a colloquial manner that is easier for the reader to accept.”

“I see,” I replied, “like the ancient writings about Socrates, and other Plato writings that were always stories. The cave-myth, for example.”

“Yes,” he continued, set on his goal, slightly irritated that I had felt the need to contribute to his monologue, “stories are relatable because they have characters. The more sympathetic the characters are, the more likely the reader is to accept, or at lest try to understand, the viewpoints expressed. An unlikable character’s argument is easily dismissed, even though we all know that an argument should be judged on its own merit.”

“Even then,” I intervened, “one cannot possibly hear all arguments in the world. And judging someone by their...

You want to write readable code. You want people to be able to understand your library, to be able to contribute within a short time from first inspecting it—you know, without messing everything up.

What makes libraries hard to contribute to and use is complexity: if your code is not immediately understandable and easy to get an overview of, you’ve already lost a lot of potential contributors or users.

Fortunately, complexity can be removed. Well, not really removed, but abstracted, composed away, and indirected. Abstracting away some form of complexity will create new complexity at a higher level of abstraction (this should be made clearer as you read along). That’s why I call it Pushing Complexity: it is pushed out to the next level.

Push complexity out of functions

Complexity has many forms (and Robert C. Martin covers many of them in Clean Code), but what I am going to focus on...

I wrote a blog post called Efficiently Rendering Web Views, which concerned itself with the difference between server-side static and dynamic rendering and browser-side rendering. I want to talk about that word: rendering. Because it’s not actually rendering.

Before the internet (but after the introduction of graphical user interfaces) the primary way of showing something on a user’s screen was simply drawing it. A program would send an instruction to the screen (this is obviously simplified), which would then draw that exact thing to the screen.

More and more programmatic abstractions were created, making it easier to quickly describe what should be drawn. This resulted in a technical representation of the items to be shown existing separately from the actual screen and what was currently on it.

Rendering is the action of drawing this technical representation onto the screen. Going...

In the following I try to learn from my experience as a young software development student working for a real company for the first time (as opposed to just building software projects for fun).

It was the summer of my first semester of university, and I had just applied for my first student job. The job was great for a student with no qualifications: it involved actual development work, and the pay wasn’t bad. I got the job.

The experiences I had at that company turned out to be very formative for me, making me set a higher bar for future employment and giving me first-hand experience with real problems in the software industry.

It happened to be just a bit after my first reading of Kent Beck’s Extreme Programming Explained (XPE), and I was excited to be working at a (self-proclaimed) Agile company, using XP in the day-to-day work. “Fantastic,” I thought, “a chance to see XP in the...

Robert C Martin recommends (in Clean Code) naming functions so that they fit in the exact use case. For example, assume you have an if-statement that accepts all values that do not contain $s:

if(input.indexOf("$") === -1)

Martin argues that the check should be extracted to exactly fit the case: [1]

function stringContainsNoDollarSigns(input) {
    return input.indexOf("$") === -1;
}

That makes the if-statement look like this:

if(stringContainsNoDollarSigns(input))

I would suggest an alternative: always implement for positive method names:

function stringContainsDollarSigns(input) {
    return input.indexOf("$") !== -1;
}

The resulting if-statement would now start with a programmatic “not” (!):

if(!stringContainsDollarSigns(input))

What are the pros and cons?

Implementing always the positive case means fewer functions when both the positive and negative can be expected...

There are three different ways to render a webpage:

1. Prerendering static pages
2. Dynamically rendering pages
3. Pages rendered in the browser

I will briefly detail the use cases and scenarios in which these three ways of rendering are used. I will also measure the performance of each of them, making recommendations for which are preferrable.

This overview should inform discussions about frameworks and rendering of views. I believe that the optimum framework will allow for any and all of these ways of rendering. Most current frameworks allow browser rendering and either prerendering or dynamic rendering, but not both.

I have chosen a simplistic, uninfluenced approach to illustrating the methods of rendering, because this will allow for a reevaluation of current paradigms and frameworks, without assuming that the existing approaches are “correct” or “the best”.

Let’s start from the bottom...

In a recent outburst on Twitter and Github, Jeremy Ashkensas and David Heinemeier Hansson argue for Romantic Versioning (versioning with heart) rather than Semantic Versioning (functionally meaningful versioning). I argue that the debate has been lacking nuance, and provide a model for deciding on how to version a given project.

Recently, Semantic Versioning has been the subject of much debate in software development circles, after a discussion about the versioning of underscore.js, a Javascript library providing functional paradigms, was brought to the masses by HackerNews and David Heinemeier Hansson.

Semantic Versioning is the idea that versioning should be functionally meaningful – that the different increments in version have a logical meaning: patch version bumps keep the current functionality and interfaces, but fixes an issue or solves a common problem; minor version bumps...

I wouldn’t recommend Scrum. Scrum is a software development process, and in order to “use Scrum” you have to adopt all of it. The process has a lot of good ideas, like daily standup meetings. It is possible to practice Extreme Programming (XP) without the pair programming, but it is not possible to practice Scrum without locked iterations.

Some companies (or, rather, people in companies) see the instruction to “use Scrum” as an instruction to focus on process. When using Scrum it is impossible to not focus – at least a little – on process, and it is hard to not go overboard. Companies end up valuing the process of Scrum higher than the communication it should facilitate.

The “Are we Agile yet?”-crowd[1] use Scrum as an excuse to not really be agile, but still label themselves as such. I have witnessed representatives from big companies discussing tiny details in the process, and which...

I recently spoke to a Software Developer consulting with the UK government. I asked him about the use of PRINCE2 in their process, as this particular project management methodology was taught as part of my curriculum at the IT-University of Copenhagen, and was introduced originally by the UK government. PRINCE2 is, in a word, elaborate. I mostly remember it as being complex and bureaucratic, two things I generally have an aversion to.

“I don’t really notice it much,” this developer said to me, “mostly I just get concrete tasks and perform them. PRINCE2 is mostly used by the project managers. It might result in some things, like I am told to write a document or create a report, and I do that, but I don’t have to think about PRINCE2.”

When I was taught PRINCE2, there was an emphasis on making all members of the team recognize their place in the model. The intention was to make it clear...