Developer growth

There is no time for empathy
After my post on empathy as an essential skill, a commenter said that the most successful developers don’t need empathy, referring to John Carmack & Linus Torvalds. Not sure about John Carmack, but Linus certainly has had a brush or two with his lack of empathy when communicating with people. There is nothing to suggest that he lacks empathy, just that he on occasions doesn’t utilize it to its fullest. But this isn’t about how a man in the open-source community goes about his business…

Continue Reading

Developer growth

Empathy: an essential skill in Software Development

Being a software developer is a tricky business. There are low’s and high’s lurking around every corner: Could this class be well-written, tested and a joy to work with or am I going to find regions of pain? Will the product demo be horrid and tedious or a joy for the stakeholders? Heated discussions, disagreements or blissful communication? Kind words or brutally honest feedback?

How can we keep up in this emotional roller coaster, while at the same time keeping up with the technology and our work? Could empathy be the secret ingredient in the awesomesauce of software development? This may very well be the case… Continue Reading

Developer growth

Dealing with feedback when it’s personal

When you  publish any content publicly on the internet, you’re opening up yourself to feedback from others. If you’re lucky someone will care enough to leave a supportive or inquisitive comment. That’s great, it means you’ve written something of value. Sometimes though, the feedback isn’t as positive. It could be that someone disagrees with your viewpoints, or approach to a topic. And sometimes it spills over to be personal. Receiving criticism is hard, especially if you’re venturing out with your content for the first time.

Continue Reading

Developer growth

My personal burnout – Lessons learned

Last week I was on the My Life For The Code podcast and had a really good talk with Shawn Rakowski (He has a fantastic blog and podcast, check them out!). During our talk we touched upon where and how this blog got started and the reasoning on the focus on empathy. I answered as best I could and the topic of my burnout came up. I speak about my burnout quite a bit since it really has been a defining moment in my (recent) life. It’s also an opportunity to follow up Jose Gonzalezrequest for an update on where I am now.

With this blog post I’d like to close this chapter of my life, but at the same time have a reference for my future self. I’ve also attempted to summarize some of my learnings and insights so as to better help others to avoid getting into this place, or maybe to help them out? Maybe even help myself.

Note: this post contains personal information that may or may not be relevant to you. I feel this gives a certain context to this very personal topic. Continue Reading

Developer growth

6 steps to avoid Developer Procrastination and set yourself up to succeed

Wednesday is my dedicated blog writing day. It’s the day I should sit down to blog for next weeks post that goes out on Tuesday. I turned up on time, but ended up doing some other nice stuff, but that didn’t help me create an actual blog post1.

Continue Reading

Developer growth

The mindful developer

Stress and fatigue are things we developers struggle with most of our careers in varying levels. There is the focus on keeping up-to-date on technologies, delivering at work, maintaining proper work / life balance – whatever that means, and countless factors that contribute to creating noise. How can we deal with the noise? Well, I’d like to explore the approach of being a mindful developer. What it means to me, and why it’s something you might want to consider looking in to. Continue Reading

Community, Developer growth

Moving past the hate in the community

The incident yesterday that shook the JavaScript community was a doozy. A developer pulled his packages from npm.js after one of his packages was forcefully removed without his consent over a legal name issue. Amongst his packages was a popular one that was used in thousands of other packages, libraries, frameworks and solutions. The article explains the happenings quite well so read that so you get the full picture before you continue….Read it? Good.

hate-cat

Oh, the hate!

This story has brought out the worst in developers everywhere. It saddens me to see the amount of hate being thrown around, and how many seem to be willing to throw more back. There seems to be a few different camps that are showing themselves here.

Haters of a company for taking legal action to forcibly remove a package due to a naming collision. Implying: A power-hungry company that doesn’t care for open source or respects their authors.

Haters of the package manager for not standing up for the package-author to try to stop said company’s legal train. Implying: A spineless package manager community that cares more about pleasing corporate vs standing up for the little guy.

Haters of the package author for reacting in such an irresponsible way, and “breaking the internet”. Implying: Irresponsible package author has lost his mind and has turned “evil” by pulling down all his packages that people’s relied upon.

Haters of developers that have put themselves into this position and made themselves dependent on an 11 line library and have broken their app. Implying: Irresponsible developers who don’t take the time and care to code everything themselves. Make it yourself instead of pulling in a dependency.

Haters of one of the most used programming languages coming out of the woodwork and calling out how useless this language is, how flawed it is and how anyone developing with it cannot be called professional developers. Implying: Developers that use this language are by default irresponsible because they don’t take programming paradigms seriously and the language is fragile and useless.

Have you considered…

I don’t have any of the background facts here except what’s in this article. But I would like to explore the possibility of approaching this incident slightly differently. Some may say naively.

Company is making a move into open source and would like to publish a package matching their brand, but there’s an existing package with same name. This is important to the company and they involve their legal department to help them figure out how to approach and request a name change. When this fails they approach the package manager responsible party and requests they remove the package in legalese. Meaning they did what they felt was right. This doesn’t mean they’ve done the right move, but they’ve done a move that is natural given their position. That doesn’t make them evil.

The package manager community is faced with a legal claim to a name, which is will win in a court-ruling. They try to broker a deal with the original package owner and also explore options that doesn’t involve pulling his package but is finally faced with reality. They aren’t an “Apple” in a position to fight the “FBI”. They give in to the demands and (hopefully) have exhausted all options before taking this drastic measure. This does not make them weak or evil or backstabbers. It’s legal doing its thing.

The package author gets a legal letter telling him to step away from his package and to rename it. Forcing that packages users solutions to stop working since they have to rename their dependency. The wording of the letter pushes his buttons and doesn’t seem inviting to a dialogue, but more “comply, or else”. He declines the request and hopes everyone can move on. When he discovers that his package has been forcibly removed, he sees no other option than to actually take a step back. He is hurt, mad, frustrated and decides to pull all of his packages. What about people who depend on the, though…? Well it’s only a few lines of code, they can move that into their project or create a new package that is maintained by someone else. He reacts to the situation that arises and does what he believes to be right.

To developers hating other for taking (small) dependencies. Have you considered that this is how many developers do their work? They don’t re-invent the wheel every time they work on a new project. Smart developers have a tool belt full of re-usable tools that can be imported into new projects to give them a flying start so they can just get going with where the added value is. Before people used to have a pen-drive with these dependencies, now we have package managers that allow us to re-use our own components and allow others to share them as well. Other smart developers realise that previous smart developers have already done this and use said shared tools and libraries. Packages can be modified, changed or withdrawn at any time, so at this time a developer can choose to lock to a specific version, make modifications on a fork with or without a pull-request or just pull it directly into their project. There is nothing controversial here. This is package management. This is the paradigm of npm-packages. Oh, and nothing actually broke in production, but it did make it hard on the development team that didn’t have a local nom cache-server.

To developers hating everything JavaScript. JavaScript has its quirks and flaws, but it is a language that can be used to create some amazing things. The latest flavors are both powerful, flexible and strict. Allowing for a more formal approach to JavaScript development. It is a tool that can be abused like any other tool. There just so happens to be a few more ways of doing so when not using good coding practices / tooling. I have seen JavaScript haters convert into lovers once they let their assumptions and opinions go and embraced the paradigms of the language. But more than that. If you haven’t taken the time to learn the paradigms of the language and worked in it, then step away from the discussion. You are now just trolling.

Ignore-haters-we.jpg

My take on it all

I don’t know the facts except what’s in this article. I choose to accept what has happened at face value and reflect on the learning opportunity that lies here.

Teams with broken builds: Fix those builds, consider pulling a dependency into your project or finding another one to depend on. It’s part of the responsibility you have as a developer to consider what makes sense to rely on or to own.

NPM: Certain trust issues have arisen. Could enforcing a policy of not being able to delete a package like Nuget for C# be an idea?

Shit happens, whether we like it or not. Pointing fingers and shouting out other people’s supposedly bad choices are not how to learn and move on. Consider framing your approach and mindset in a way that brings value to the topic at hand since you may have very valid points. Don’t let that drown in all the noise.

Update: Kik messengers side of the story

Update2: npm.js official take on the story

Update3: npm.js concrete action to improve

I would love to hear your thoughts on this matter. Feel free to drop off a comment or reach out to me

Photo credit feature image: Brian LeRoux via Visualhunt / CC BY-NC-SA

Craftsmanship, Developer growth

Unlock your true developer potential through blogging

Update: I no longer recommend John Sonmez or his content.


So, you’re a software developer pushing boundaries and earning a living by writing code. You learn as part of your job or maybe by dabbling in projects or reading about the latest trends. You may be spending time, consuming content to learn awesome technologies and feel like you’re in a good place. But have you considered that consuming content as a way to keep up to date may not be the best way to learn? You most certainly will get to know about trends and technologies, but you won’t really be learning new skills. Continue Reading

Developer growth

Reflections on “The Ten Commandments of Egoless Programming”

I stumbled over The Ten Commandments of Egoless Programming which supposedly hail from the book The Psychology of Computer Programming, and found them fascinating. I haven’t read the book but loved the idea so much that I thought I’d attempt to write down some of my thoughts. As an experiment I’ve taken the “commandments” and written my interpretations. These may or may not align with the original authors interpretation.

The Ten Commandments of Egoless Programming

  1. Understand and accept that you will make mistakes.
  2. You are not your code.
  3. No matter how much “karate” you know, someone else will always know more.
  4. Don’t re-write code without consultation.
  5. Treat people who know less than you with respect, deference, and patience.
  6. The only constant in the world is change.
  7. The only true authority stems from knowledge, not position.
  8. Fight for what you believe, but gracefully accept defeat.
  9. Don’t be the “coder int he corner”.
  10. Critique code instead of people – be kind to the coder, not the code.

Continue Reading