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
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.
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
I stumbled over a slightly different manifesto the other day. Or it was a legion actually. Developers taking up arms against a travesty of the C# language: #regions. You can read it at http://anti-region-legion.org. So what is the legion all about? Here’s the message from the website:
The Anti-#region Legion is a community for people who believe that the C# #region is an unfortunate part of the language.
I saw this and thought I was behind it completely, but decided to revisit my previous experiences and assumptions on the matter before concluding. Continue Reading
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
We’re sometimes placed in situations where we need to present our software to stakeholders, business owners or end users. These users may or may not be technical, but they will most likely be the other side of the user interface you are creating. They are the reason you create software and are genuinely interested in the end result. In recent years, with Agile and Scrum, these presentations tend to take place more often and you’re in the limelight presenting the latest and greatest. Many years of honing our skills as software developers have all but prepared us for this challenge, and we may end up getting a response from the attendees along the lines of this:
Too much uptight focus on technical details, digging deep into issues that nobody cares about, discussing the framework, library or platform chosen to solve a particular problem leaves you attendees bored, confused and sometimes feeling dumb since they haven’t got the faintest idea what you’re talking about. This leads to frustration, arguments, cold-fronts or just a general feeling of “meh”, where developers, stakeholders and users just don’t get the value out of this important meeting arena they could.
So what’s a developer to do? Here are some tips and thoughts for preparing for, presenting and participating in more technical presentations.
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
- Understand and accept that you will make mistakes.
- You are not your code.
- No matter how much “karate” you know, someone else will always know more.
- Don’t re-write code without consultation.
- Treat people who know less than you with respect, deference, and patience.
- The only constant in the world is change.
- The only true authority stems from knowledge, not position.
- Fight for what you believe, but gracefully accept defeat.
- Don’t be the “coder int he corner”.
- Critique code instead of people – be kind to the coder, not the code.