Left On The Web

You Need to Do What You Need to Do

| Comments

One of the topics in The Art of Asking that I think more developers should be aware of is that you need to do what you need to do to do your thing. This sounds vague, but it is true. In the book, Amanda Palmer uses several examples of how this works for artists, but I think it is equally true for developers (although not everyone understands this):

At some point, Amanda is having a coffee with Samantha Buckingham, another crowdfunding artist. She releases her music on Patreon, and Buckingham was afraid it would not sit well with her fans that she would post pictures of her sipping a mai tai. After all, it was her fans’ money being spent on such a holiday. The response Amanda gives:

What does it matter where you are or whether you’re drinking a coffee, a mai tai, or a bottle of water? Aren’t they paying for your songs so you can… live? Doesn’t living include wandering and collecting emotions and drinking a mai tai – not just sitting in a room and writing songs without ever leaving the house?

Then she goes on to describe how Kim Boekbinder, another crowdfunding artist, thinks about this:

Kim had told me a few days before that she doesn’t mind charging her backers during what she calls her “staring-at-the-wall time,” which she thinks is essential before she can write a new batch of songs.

This attitude is important for us as well I think. Someone, many developers I encounter seem to think that you need to work furiously on writing new code, at least 8 hours a day, to do your work well. But this is far from true. I touched on this subject in this blogpost, but programming is a creative job. This means that sometimes, you need to take a step back. Go out for a walk, play a game on your Wii, Playstation or XBox, read a bit in a book, find the activity you need to get that inspiration. And don’t feel guilty about doing it.

In my previous project, the office cafeteria actually had a pool table. At least once a day, I’d go down to the pool table with a co-worker and play some pool. I surely wasn’t banging on my laptop for 8 full hours every day, but the games of pool surely helped me sometimes in finding the solutions or cooling down after a frustrating bug arose. Sometimes, we just need this change of scenery. Remember, you get paid simply to get the job done, regardless of how you do it. If your employer or client gives you a hard time about it, just tell them that you need this in order to do what they pay you to do.

As Amanda Palmer puts it quite nicely:

The relative values are messy, but if we accept the messiness, we’re all okay. If Beck needs to moisturize his cuticles with truffle oil in order to play guitar tracks on his crowdfunded record, I don’t care that the money I’ve fronted him isn’t going towards two turntables or a microphone. Just as long as the art gets made, I get the album, and Beck doesn’t die in the process.

The Judge

| Comments

Sometimes it feels like we are in a constant courtroom: We, all of us, constantly judge other people. And I mean, constantly. The person you see on TV, the person that walks by you on the street, the person that comes to your door when you get a delivery. The judging can be based on all sorts of things: How they look, smell, walk, sit, or do something, what they say, what they believe, who they love. It usually doesn’t even happen consciously, it is something you do automatically.

Judging is not always a bad thing, but we judge people too much and too soon. In the past month or so, I’ve been consciously looking at when and how I judge, and I was shocked at how often I do it, sometimes based on, well, nothing special. A quote I hear on the news, a tweet. Yes, even – sometimes – on how they look. I was shocked.

The effect on the people being judged can be horrible. It can make people insecure, it can create an atmosphere of hostility, it creates a society or community in which we don’t dare ask, or even show our vulnerable side.

In The Art of Asking, Amanda Palmer talks about her time as a living statue in the streets of Boston. About how she found out that she could earn a stable living being a living statue. And it isn’t just about standing there, she actually created a connection. Her goal was to create a connection between her as a statue and the people giving her money. But then people shout at her “get a job!” as if being a living statue isn’t a real job. Those people judged her, without even knowing her and why she was doing this. They simply discarded the possibility of this being a real job while for her, it was a real job.


Last week, I was chatting to a friend. We were talking about, well, life, work, etc. At some point, it was clear something was bothering him, and he didn’t dare ask for help. He was honest and told me he was afraid that I would judge him. Of course, he didn’t know I had so consciously been observing my own judgements of others. Especially with friends though, especially when they ask for help, I do not judge. I do not want to judge. Because asking for help is a big step. Big enough for me to know that – apparently – help is necessary. And if I can help, I will. Without judgement. Eventually, the question was asked, and I helped. Problem solved.

Some time ago, I wrote:

Asking is easy if you just do it. Once you start thinking about it, it becomes hard.

I didn’t really go into why it was hard once you start thinking about it. I guess it mostly has to do with judgement. You are afraid the person you ask for help will judge you, will think you are stupid, will think that you acted stupid, will think you are weak.

We miss information

The worst thing is: we miss information when we make useless judgements. Usually, they are made based on assumptions. They believe in God? Why are they so stupid! They believe in Allah? They must support violence. They vote for the right-wing populist party? They must be racist. They are fat? They must eat bad. They use PHP? They are not real programmers. A woman? She must be the front-end developer or designer. A conference with mostly male speakers? They must not have made an effort to get in female speakers. That guy stole something? Such a stupid criminal.

It is easy to judge people, but perhaps if you knew more about the situation, you wouldn’t jump to conclusions that quickly: Perhaps the guy that stole something did so because he has a hungry kid at home and recently lost his job. Perhaps stealing something was his last, desperate attempt at taking care of his kid. Perhaps the person voting for the right-wing populist party does so because they disagree with the economic policy of your government, and no other party has a strong opinion against that policy. Perhaps the fat person is simply ill.

The effect

The effect of my conscious effort to look at my judgement and trying to do less of it is interesting. I feel like I am more open to other people and to their ways of seeing things. I also experience less negativity. You usually judge other people because you do not agree with them based on the limited information you have, which usually leads to a verdict: They are not cool, they did not do what they should have done, they are stupid, they are worthless, they live an unhealthy life, their belief is stupid, they are sinners. Do you see what all these verdicts have in common? Negativity. Trying to reduce the useless judgements has surely reduced the negativity in my head and in my life. What do I gain from judging the person on TV? Nothing. At all.


Our community, the PHP community, has been becoming less and less friendly. We seem to judge more these days, and be very vocal about it. It splits us up into groups, smaller groups of likeminded people. And that is a shame. Sure, we’ve had framework “wars”, CMS “wars”, etc, but most of that was more like a bunch of joking between friends. These days, once we disagree with eachother, sometimes it goes much further than joking.

It can be different. Since “finding” Amanda Palmer last year, I’ve been getting more and more impressed with her community. Of course, Palmer is very vocal about welcoming everyone and spreading love and joy, so the people that are her fan are more likely to take that up, but I’m so impressed with it all. It feels so much more friendly and welcoming. And people are actually willing to share their fears, their loss, their personal stories. People accept everyone for who they are, and support them when they need it.

I think we, the PHP community, should try and be more like that. Judge less, and be more open and welcoming. If we do that, and don’t judge the next woman, man, gay person, vegetarian, rabbi, junior developer, WordPress developer, broke person, left-wing voter, right-wing voter, non-voter, anarchist, rapper, grumpy person, etc then I believe we will be a more diverse community. You will feel better because you have less negativity in your life, and the other person will also feel better, because they will feel welcome, not feel judged. It is a small change in your mindset. Not an easy one, but not a big one either.

I Want to Support

| Comments

I have been blogging in the past months about asking, as I think it is quite important to realize asking is not wrong at all. When Joshua posted his slightly controversial post about elePHPants I felt it made a good point: We should be donating more to open source projects.

It inspired me to create a simple new site listing donation options in the Open Source world, but as I was trying to find content for it, I found out that many open source developers and projects don’t list donation options on their website. I think that is a terrible shame. I know the idea of Open Source is that you give it to the community, and that people can thank you by contributing, but sometimes when you use Open Source you just want to buy the developer a beverage of their choice or help them unwind by letting them afford a new game.

Introducing I Want To Support

As I mentioned earlier, Joshua’s article inspired me to create a site that lists donation options. So I sat down earlier this week and started playing around with Sculpin, one of the projects that I’d heard of but hadn’t actually tried myself. It took me about an hour, or perhaps an hour and a half, and I had the basic idea of the site set up.

What the site basically does is list projects that accept donations. The homepage lists the projects, and you can click on a project to get more information on donation options.

So when you have some spare money that you want to donate, you go to the site, pick a project to your liking, and donate. It is that simple. That is the idea behind I Want To Support.

The content comes from an open Github repository. Adding a new project is as simple as creating a Markdown file that adheres to the template. Everyone can create pull requests to add projects they know. So if you know a project that accepts donations, please do add it to the list.


Of course, donating to Open Source projects does not mean you can not contribute in other ways anymore. Please do keep sending pull requests, writing documentation or blogposts or helping your favorite project in the ways you’re already doing.

Take the Scenic Route

| Comments

Yesterday was a really hard day at work. Lots of meetings, tough topics, lots of stress, lots of frustration. So when I went home, I didn’t take my usual route, but decided to exit the highway a bit earlier than usual and drive through the forest.

Relax And Clear Your Mind

Driving through nature, whether it is a forest, a moor or meadows, has a calming effect on me. It allows me to clear my mind and just enjoy the moment. It also takes you away from the daily routines you have, take a distance from what you see every day and have some variation.

This Also Works For Programming

And while the above is a real thing, it can work just as well as an analogy for being stuck in a programming problem. Sometimes, you just need to step back and take the scenic route. Try a different solution than the one you’re stuck on, find another way. Modern version control lets us easily stash one solution to work on a different solution. You could even stash your second solution and work on a third. Eventually, you will find the right one. It could even be your first solution, but you might not realize it until you’ve tried the other solution(s).

Get Off Your Route

So when you’re stuck, try the scenic route. This means not trying to solve the problem using the same approach you’ve used before, but try a different approach. Completely break with your current path of choice and think of other ways you could solve this problem.

Also: Get Off Your Route

Programming doesn’t stop the minute you step into your car, onto your bike, into your bus or train. So analogies aside, take a different route home every once in a while. This might just force your brain to also take a different route, see a different approach, consider a different way of handling the same issue. And if that doesn’t work, at least you’ve enjoyed the scenic route home.

Finding a Job Without a Recruiter

| Comments

Earlier this week we had a discussion in the PHPNL Slack chat about finding jobs and using recruiters for this purpose. Some people had used recruiters to find their job and were stating that they might not have found their current job without the recruiter. I disagreed, and eventually promised to blog about it to share my ideas about finding a job without a recruiter.

About recruiters

First of all, funny enough, most developers seem to agree recruiters are (with a few exceptions) horrible people. Their only focus usually is money, not making the connection between a person and a company that seem to be a good fit.

I agree with the above. There are a few exceptions, people who really do care about the people that they represent as well as the companies they represent, but I’ve dealt with too many recruiters that:

  • alter CVs
  • send 10 CVs to a company at once
  • send random e-mails to everyone in their database, regardless of any matches in skills vs requirements
  • actually call people at work to try and get them to change jobs

And that list can go on and on and on.

Reasons for using a recruiter

Talking to people who have used a recruiter before, the main reason for using them was because recruiters have knowledge about jobs that they don’t have themselves. In the past you could just Google for jobs and find them, but these days using Google to find a job usually results in finding tons of recruiter websites, and not the sites of the actual companies looking for people. Does this means Google has no use when looking for jobs? It is perhaps less useful, but definitely not completely useless.

Another reason for using a recruiter is that they want to look for a job “below the radar”, and recruiters usually anonymize their CVs and profiles and hide the current employer. While this may sound like a valid reason for using a recruiter, I’ve seen CVs of candidates being offered to their current employer, or seen CVs that, even anonymised, were pretty clear in who it was.

Perhaps the most honest reason I’ve heard was “I’m lazy”. I believe this is also the only really valid reason for using a recruiter. I can’t counter this argument at all: If you’re lazy, using a recruiter is most probably the easiest way of finding a new job.

Reasons for not using a recruiter

First and foremost: The majority of recruiters do a horrible job focussed just on money. They don’t (seem to) care about the people they represent and the companies they represent, their only focus is the bonus they get out of it. They create a really toxic environment for jobseekers as well as companies with job openings. The fact that these days you can’t even use Google in a simple way to look for a job without finding dozens of recruiter websites is enough proof of that. Now if they were doing a good job finding matches, that would be OK, but in a lot of situations they lie, twist, hide the truth and misrepresent developers and companies. Using recruiters to find a job keeps this toxic environment alive. This alone should be enough reason to not use recruiters.

Keep the above in mind also for yourself and your image towards potential employers. I’ve heard of numerous situations where after a very nice job interview that was positive from both sides, either the developer or the employer got the message “yeah, the developer just isn’t interested” or “the company is not interested in hiring you”, while there was a clear interest. The reason they say there is no interest is because in the negotiations for the recruiter fee, the recruiter didn’t feel like they got enough money, so they lied to both parties. After a good interview, this reflects really bad on you. Based on an interview, your potential employer can get certain expectations, and when they hear you’re not interested (or worse yet, when they hear you think they offer way too little salary while you don’t actually think that) this reflects poorly on you.

Many recruiters are known for their bad business practices. I once went to an interview for a company that was really excited I was interested in working for them, because my CV was the perfect match for their job! We had a really good interview, up until the point where they asked me what kind of C++ projects I had done. I was confused. I had never done any C++, and surely this was not on my CV. “Well, your CV here lists you with a couple of years of C++ experience”. The recruiter had altered my CV to include experience I didn’t have to make me a better match, in the hopes of it not being noticed.

Another good example is the recruiter that I accepted on my LinkedIn. A couple of days later, I got several messages from people I know asking me why I recommended them for another job. I was confused. I did no such thing. It turned out that the recruiter was just going through my LinkedIn network, calling everyone he could find a phonenumber for telling them that I had “recommended them for this position” that he was trying to fill. I was pissed, and ever since then I do not accept LinkedIn requests from recruiters anymore.

And then of course there’s the recruiters that misrepresent themselves. The best example must be the guy that started a new meetup group in Amsterdam for PHP developers, and signed all his e-mails with him being the “Amsterdam PHP Community Manager”. Of course it was just a coincidence that there was actually an AmsterdamPHP (note the absence of a space here) meetup group as well, a quite popular group. Even after being told that this group existed, he kept on using this title for quite some time, purposefully trying to scam his way into the lives of PHP developers.

Long story short: The chance of you being misrepresented by a recruiter is huge and this may reflect badly on your image towards fellow developers as well as potential employers.

Looking for a job

So if you decide not to use a recruiter, how are you going to find your next cool job? Well, there’s enough ways to do so.


With all the people doing “incorrect SEO” it is getting harder to find the stuff you really want to find, but that mostly means you have to use some Google-fu. Find the keywords that recruiters use and use “keyword exclusion” to remove those from the results. I’m thinking of terms like “rockstar” or “ninja”, for instance. There are companies that also use those terms, but really, would you want to work for a company that considers you a rockstar or ninja? I wouldn’t. Aside from a couple of companies it is mostly the recruiters that are looking for a rockstar or a ninja, so excluding those words from your search results will help you avoid recruiters.

You can also use the recruiter-powered websites to your advantage. Recruiters are usually smart enough to remove the company names from their job openings, but with a bit of common sense, it is often easy to find out which company they are recruiter for. The location, the required skills and what they are offering are often great indicators of what company is looking. Use your common sense and Google to find out what company is looking. Also, most recruiters are pretty advanced copy-pasters, so just using Google to search for one or two sentences from the job opening can give you the website of the actual company that is looking for people.

In-person (aka: The community)

The best way to find a good job is to actually talk to people. Go to a local usergroup, attend conferences, join mailinglists or forums, go on IRC. There’s several community-oriented Slack networks these days (such as the PHPNL that I mentioned before). All of these are great places to meet people and hear about exciting new opportunities. Remember we’re currently living very much in a developers’ job market, so companies looking for people will broadcast their search in many places. Interacting with the community will expose you to a lot of their opportunities and hopefully get you in touch with the best job for your current search.

Meeting people in person and talking to them also allows you to get much more insight into the companies that have job openings. Often you don’t talk to their HR people but you first talk to their developers, meaning you can get a good idea of what the jobs are about, how they work, whether they are a good fit for what you’re looking for. Developers are usually (not always) quite honest about their work and employer, which is a good thing.

In most communities there are also a few key people that have a good overview of available jobs. I’d like to call them the Community Recruiters. They are usually thought leaders, user group organizers, conference organizers etc. They have a lot of connections and contrary to “professional” recruiters they don’t want money for their services and actually care about people finding the job they really want. Some people I consider to be community recruiters are Cal Evans, Michelangelo van Dam and Rafael Dohms. There are many more. Identify the Community Recruiters in your local community and let them know what kind of job you’re looking for. There’s a very good chance they’ll be able to help you either find the job or at least get in touch with the right people that may be able to connect you with a good job.

Job boards

Generic job boards (like Monster.com) are unfortunately taken over mostly by recruiters these days, so finding a job there is not easy if you want to avoid recruiters. Fortunately, there’s some specialized job boards available these days that can help you find a job. For instance, if you like working with Symfony framework, there is the Symfony jobs section, for Laravel there is Larajobs. There may be some recruiters there, but most of the ads on those job boards are placed by the actual companies looking for developers, so you will have direct contact with the companies instead of through recruiters.

Stack Overflow (the solution to most programming problems these days) also has a careers website. It is a mixture of recruiters and companies from what I can gather, but there’s a lot of companies that put their job openings there directly so you can get in touch with them, research them etc.

Try the obvious choices directly

Think of your work. Think of what you do. Which technologies you use. Which products. Which frameworks. Which hosting. Which events do you go to? Then identify which companies are related to that. These are the obvious companies in terms of work you might like to do. Then check their websites for job openings. Try the most obvious choices first. There’s a good chance you’ll find at least a couple of potentially interesting jobs when doing this. Perhaps you don’t need to look beyond this.


Some years ago when I was looking for a job, I tweeted about it. Within a week, I had 10 (ten!) interviews lined up. Twitter is an amazing place to look for a job, because it is open and extremely interactive.

However, because Twitter is so open, there is no way to do a covert search for a new job without your employer finding out. However, if you follow the right people, the jobs will be delivered to you. The community recruiters I mentioned earlier often retweet cool jobs, and there are many more community leaders in the PHP world that (re)tweet jobs as well. Follow those people and you’ll be sure to get the jobs delivered right to your (twitter) doorstep.

Decide what you are looking for first

Most importantly though, whether you are using a recruiter or not, is to decide what it is you are looking for. This will make your search a whole lot easier. Determine what makes you happy in terms of technology, projects, customers or product development, salary, etc. This makes it a lot easier to company possible jobs to your requirements and will help you find the right job. Sometimes, when making the requirements you can already conclude that because of those, you should or should not use a recruiter.

On Code Reviews

| Comments

Recently we’ve had some discussion on the PHPNL Slack community about code reviews. It’s an interesting topic that I’ve been meaning to blog about for quite a while already (and I’ve written about it for Wisdom of the elePHPant), so this was a good reason to sit down and actually put down my thoughts on code reviewing.

So what is it?

Code reviewing is exactly what it sounds like: It is reviewing code written by another developer. There are different ways of doing this, but in the end it all comes down to having at least one other set of eyes checking any code written before it is released.

There are many reasons for doing code reviews. It can be to prevent security issues, to ensure correct performance of your application, to prevent bugs but eventually it all comes down to the more generic term of ensuring the quality of your application.

How do you do code reviewing?

There are many tools that will help you with code reviewing, and I can’t give you The Perfect Tool For The Job. What currently works well for many people is using the approach with Git where you send a pull request. Most Git-tools (such as Github and Stash) have excellent interfaces for going through the diff between a feature/bugfix branch and the main branch. They allow you to add comments with every line of code, so that the author of the code knows exactly what you’re commenting on and is able to fix the right code easily. Similar tools also exist for many of the other version control systems out there.

While tools can make your job easier, it is not necessary to use them. You can go through a diff when using your version control system from the commandline, or you can even go through the code together with the author of the code while sitting next to eachother (or while using screensharing with Skype/Hangout).

Preparing the review

As a developer I always make every change (feature, bugfix, improvement) in a seperate Git branch. The branch is pushed to my fork of the main repository, so once I’m done with my change I push the branch to my fork. I then create a pull request against the main repository. The PR description should contain useful information: A link to the (Jira) issue this is a PR for and possibly some generic information on what you’ve done in this specific PR and what choices or assumptions were made.

When the PR is created, I immediately review it myself. Reading a diff on Github or Stash is completely different from working in your IDE, is my experience. I look at my code in a different way and often I spot small bugs, forgotten changes or useless changes in this mode that I don’t when actually working on the code. I often also spot forgotten docblocks and such pretty quickly when reviewing my own code.

Doing the review

When I sit down to do a code review of code written by someone else I open up the pull request I’m about to review. I click the link to the Jira issue to check what the code is supposed to do and then start looking at the code. I focus on many things: Does this logic indeed implement the feature requested, but also: Does it follow the standards. I am known for nitpicking over docblocks, typehints and such.

Depending on the testing strategy in your organization, this is also the time to check if all code has accompanying (unit) tests, and whether they are actually good tests. Testing is a subject on its own of course, but it should be part of your review to check if the tests are there and good.

For everything I find, I place a comment. Even when there are several places in a file or PR that have the same “issue”, I place a comment in each place. I’ve gotten some feedback that some people don’t like this and prefer “check this PR for x, there are several places where this occurs”. This is a personal preference, but I prefer getting the comment in every place where it’s wrong, because when running through the feedback for a pull request it’s easier to know exactly what you should update where.

When commenting, pay attention to the way you write your comment. Code reviews are a check of the code, not the developer. Comments for that reason are not an attack on the person, but should be directed at the code. Explain why something is, according to you, not the right implementation, why you’re commenting, why you think it should change. Always keep in mind that there is a human being on the other side of the pull request that needs to handle the comments.

When code and/or documentation isn’t clear: Ask questions! You can ask the developer directly but you can also add a comment with the question. Reviewing is not something you do once per pull request and then forget about, a pull request can actually contain whole discussions and conversations. It is wise though to keep this to a minimum and when it turns out there are discussions/conversations going on, try doing this directly and put the conclusion in a comment so that the pull request does contain the information that is important to decide whether the pull request can be merged.

Functional review

While working at Enrise for a project some time ago, I got introduced to the concept of also doing a functional review of a pull request. Every pull request should be reviewed by two developers other than the author, and one of the developers is also supposed to do a functional test of the pull request. This means you don’t just check the quality of the code, but also the functionality. I really like this approach. Code is only code, it doesn’t turn into functionality until you actually execute it.

Processing the comments

Back to looking at the review from the developers perspective: Once your pull request is reviewed, it is up to you to process the comments. This definitely doesn’t mean you actually have to do exactly what is said in the comments: Look at every comment and see if you agree. If you agree, implement a change to process the comment. Otherwise, respond to it to state your position on the subject. As mentioned above, when it looks like it is going to turn into a discussion, it is better to not do that in the pull request but instead do a direct conversation and only document the conclusion of that. When you decide not to follow up on a comment, make sure to explain why.

As mentioned before, a code review is not a “check once then it is fine” thing. Instead, it is a play between all participants in the code review that goes on until the pull request is approved. So when you’ve made your changes to your pull request, you send it back for review and another review may happen.


Depending on the organization you work for and its strategy in these things, once the reviewer(s) approve of the pull request it may be merged immediately or will be merged during the preparations of a release. Approval is usually the moment where you’re done, your (Jira) issue can be moved to the next step in the process and you’re done. Congratulations, you just contributed more good code to the project!

Who reviews?

I personally think that in a team of multiple developers, everyone reviews. Not just the seniors should review the code. Depending on team size, you’ll make a decision on how many people should review a specific pull request though. When you have a small team, you’ll probably want one other developer to review, but when you have a bigger team it’s a good idea to have at least two people review each pull request. This should give a more balanced review than just a single developer.

Seniority should play no role on deciding who reviews. Senior developers usually have a pretty strong opinion on how things should be done, but are sometimes also stuck in certain patterns. It can be refreshing to have a junior or medior do code reviews because they may comment on things that seniors don’t pay attention to or that they don’t see. Aside from that, code reviewing can be a great way for a junior or medior developer to see how other developers approach certain problems and implement certain features. The learning goes both ways!

Group reviews

Aside from the system where each pull request is reviewed before it is merged, it can also be a good idea to do group reviews every once in a while. You’ll need a laptop, a beamer and your codebase. One person controls the laptop and as a group you go through your codebase. Everyone is allowed to speak up when they see something weird in the codebase, which then causes a discussion (well, usually ;) ) that can result in an improvement ticket in your issue tracking system.

In group reviews it is just as important to realize that comments and discussions are not critizing the author of the code. It is an effort to improve the quality of the codebase. As such, don’t offend and do not take offense from anything discussed during a group review.

Code reviews when alone

Doing code reviews when you’re a freelancer working on your own can be hard, but not impossible. There are many ways of doing this. The easiest is to find a group of likeminded freelancers that are willing to exchange favors. Those favors can include doing code reviews for each others projects. The feedback that another developer can give you is invaluable and can really lift your codebase to a higher level. Especially when working alone, this can be very important for your personal development and for your code quality.

Code reviews in the QA ecosystem

It is important to realize that code reviews are part of the QA ecosystem. As such, they can not replace other parts of that same ecosystem. You can not replace code reviews by a setup with PHPMD, unit tests, PHPCPD etcetera as you can not replace those tools just by code reviews. They should be done side by side to get the best out of all those tools.

Solving ‘Convert: Delegate Library Support Not Built-in `white’ (LCMS) @ warning/profile.c/ProfileImage/853’

| Comments

Another quick fix documented here simple because it may help me (or someone else of course) in the future.


For a project I’m working on right now I need to crop an image using ImageMagick. We’re using the commandline instead of Imagick because we need to execute a custom command with a lot of extra options for this specific action, since the image will eventually be used for high-quality printing. As I was testing the command, tweaking the parameters, I eventually ended up with an error:

convert: delegate library support not built-in `white’ (LCMS) @ warning/profile.c/ProfileImage/853

The solution

It turns out this was very simply to solve: I used homebrew to install imagemagick, and I installed it simply by doing:

brew install imagemagick

Apparently, this is wrong. At least when you want to specify your own profile (for instance by using -profile /path/to/sRGB_IEC61966-2-1_black_scaled.icc). The solution? Install it —with-little-cms:

brew install imagemagick —with-little-cms

With thanks to clee704 on Github who came up with this solution.

SSL, Composer and PHP 5.6

| Comments

A quick technical note: I ran into the same issue as Rob Allen did. Using his solution I came to understand the problem, but contrary to Rob, I was using an Ubuntu system in a Vagrant-box.

The solution is the same, the path is different. In your php.ini, you add/update the openssl.cafile parameter:


Don’t forget to also restart Zend Server if you’re going to use this through the webserver as well. Thanks Rob for your blogpost and Cees-Jan for finding the right path to this file.

Coming Out of the Box

| Comments

Asking for help. Once you start thinking about it, it is really hard to do. It doesn’t really matter what you need help with, it is hard once you start wondering whether you should ask.

In The Art of Asking Amanda Palmer writes about Anthony. Anthony is a professional therapist who helps people in hard times. Anthony is also Palmer’s best friend. He helps her a lot, either by listening, by asking questions or by giving advice. But once Anthony himself is in a dire predicament, all of a sudden, it was hard for him. She writes about this:

He likes being in control, he loves having answers, he loves fixing and helping people. But he has a really hard time letting people help him. Sometimes, when he gets depressed, he shuts down and doesn’t like to talk. When that happens, I figure it’s time for me to step up, ask him questions, help him through, talk about the problems. Be he clams up and doesn’t like talking to anyone about his own problems. He calls it Going Into The Box.

Triggered by both this book and events in my own life, I’ve been thinking a lot about “asking”, and have been thinking about how I handle asking, and I’ve come to an interesting conclusion. Asking is easy if you just do it. Once you start thinking about it, it becomes hard.

I really recognize myself in Amanda Palmer’s description of Anthony. I, too, have (had?) a tendency to completely turn inward once I have a hard time. The trigger can be anything from worries over something to stress, but not even my wife will be able to get through to me in such a situation. Why? Because I don’t want to ask for help. I don’t want to be a nuisance to other people, don’t want to bother them with my own problems. Recently though, I’ve started talking about it to my wife, asked her for help coping with something, and it turns out that once I do that, the problem gets much easier to handle. I can cope.

On the other hand, when you don’t really think about it, asking is easy. In the preparations of WeCamp, we were so excited about our concept and the way things were shaping up that without much hesitation I sent some people an e-mail asking them to be a coach at the event. Being a coach would basically mean “being on an island working for a week, and not getting paid for it”. But I didn’t think before asking, I just did it. And the response was excellent. Not everyone I approached could to it, for a variety of reasons, but I did not have a hard time asking. Why? Because I did not think about it before asking. I just sent out the e-mails and did it. Because I was really excited about what we were trying to do.

I’m trying to train myself to ask more. Sometimes, this may be annoying but I’ve found asking works. If people do not have the time to help or even answer your question, they’ll just let you know. Most people actually love to help once they’re asked. I know I do, which makes it even stranger that I didn’t understand that asking would probably result in the same help I give when someone asks me.

Try to be like Anthony when it comes to helping. Try to avoid being like Anthony when it comes to asking help. Come out of that box.

We Are All Artists

| Comments

I’ve written on this topic before, but as Amanda Palmer touched the topic in her book I felt it was a good idea to write about it again, this time on my blog. Especially since the angle is slightly different.

In my contribution to Stuart Herbert’s book I talk about the need to be proud of your work with the angle of ensuring a certain quality. However, there is also the other way of looking at it. I’ve talked to a lot of people who at some point in their career (often early on in their career) had a hard time being proud of their work because their work can not be seen. Designers and frontend developers can very easily show their work. “Hey, look at this cool site I’ve designed!” For backend developers, this is very hard. “Look at this site, we’ve worked hard for 3 months building it!” “It’s just a webshop, so what?

In her book, Amanda Palmer speaks about a phonecall she had with her mother who had been a computer programmer for 40 years. Amanda Palmer, being a pretty clear and proven artist, at some point gets confronted by her mother with something she said when she was 13:


Not long after, however, her mother says exactly the thing I’ve wanted to say to many of the developers I mentioned above that didn’t know how to take pride from their work:

You know, Amanda, it always bothered me. You can’t see my art, but… I’m one of the best artists I know. It’s just… nobody could ever see the beautiful things I made. Because you couldn’t hang them in a gallery.

This is the message I’ve tried to get across to many developers in the past years. Sure, you can’t show non-programmers your work of art. Even if people can appreciate the amount of effort that goes into building software, many a mother, brother, nephew or neighbour would not be able to understand the difference between your building a high-end high-performance architecture and someone that “just makes it work”. But that doesn’t mean you stop being an artist. YOU ARE AN ARTIST. You need to solve your problems, implement your features, you need to be creative. Being a software programmer is creative, just as being a musician is creative. It’s just a different problem you’re solving.

So please, PLEASE be proud of what you do. We are all artists.

Update: Bart de Boer pointed me to a 1995 interview with Steve Jobs in which he mentioned the exact same thing. If even Steve says so, do you believe it now? ;)