There is no time for empathy
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
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.
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 Gonzalez‘ request 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
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.
Here I am commenting on others great stuff avoiding my designated time for writing a blogpost. At least I’m spreading _some_ value.
— Pavneet Singh Saund @ Gran Canaria 🏳️🌈 🙌🏽 (@pavsaund) March 30, 2016
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
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.

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.
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.

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
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
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.