Empathy – the 4th most popular word in 2017, according to Merriam-Webster. It’s interesting that this word has risen up in its popularity this year. Mirriam-Webster also points out the connection between politics in the USA, and the increase usage and searches for empathy.
Here’s Google’s take on how empathy is doing 2017. This is a trend graph compared to sympathy and compassion:
We’re coming upon the end of another year. An eventful year that may have left you with a mix of feelings. Some people wish for 2016 to just get over with and hope for a more positive 2017. I won’t dwell on those aspects. Let’s let the years events be and do what we must to improve and make it better.
On a personal note, I’ve come a long way in the past year and as a result, so has this blog. It’s hard to imagine I was just coming out of a period of burnout, struggle and depression. My recovery manifested itself into the journey that is this blog and everything that’s spawned out of it. I’ve made some wonderful connections along the way, and what better way to celebrate the end of the year than to celebrate these connections? Continue Reading
Inspired by Torbjørn Marø’s writeup on his planned agenda for NDC 2016, I’ve written my own initial plans.
In my role as a team lead at KomplettDev I’ve started leaning naturally to topics on people / softskill / agile.
I’m not leaving technology behind , though. There are exciting things happening in the .NET cross-platform space, and it’s good to get up to speed with ASP.NET Core. We’ve just started with ReactJS, and it’ll be good to get some feedback from others’ experience using the technology in the wild.
There’s also the possibility that I’ll jump on a few architectural and deployment sessions.
This year there’s a twist though. I’ll be attending a conference as a speaker for the first time! My colleague, Tomas Ekeli, and I will be speaking about how we’re scaling our team and architecture at Komplett in the session “Making Komplett big by going small“. We were a late entry to the conference and have naturally been placed in the last available slot.
I expect Friday to be filled with last-minute preparation, thoughts, nerves and whatever else is natural when speaking at a conference for the first time.
Probably the most important long-term effect of attending a conference like NDC Oslo is the social aspect. Because of the way the event is organized there’s a natural focus on being social in the breaks. I’m looking forward to meeting old friends, and making new ones.
Among the people attending the conference there’s one I’ll bring up: Dave Rael, the Developer on Fire. It’ll be great to finally meet Dave in person after being a guest on his podcast, and getting to know him through twitter / facebook-group.
As you’ll see there are just so many awesome sessions going on in parallel, so many last-minute decisions will be made on the floor!
As with any plans, they can be changed, and most probably will. I may sit out a session or two. Or maybe just socialize near the community area, representing NNUG (Norwegian .NET User Group).
So here’s my tentative agenda for the 3 days at NDC Oslo. Please reach out and say hi if you’re there.
Versions are evil – how to do without in your API – Sebastien Lambla
The sane way to build cloud infrastructure – Paul Stack
Scale up and out with Akka.NET – Roger Johansson
Universal web with npm, React and Redux using WebPack – Jake Ginnivan
Domain-Driven Design: The Good Parts – Jimmy Bogard
An Experience Report from Building a Large React.js/Redux Application – Jeremy D. Miller
REPL Driven Development, Scrum, and the Wright Brothers – Jamie Dixon
HTTP 2.0 from the Developer’s Viewpoint – Dave Methvin
Working Distributed – How Does It Even Work? – Brendan Forster
.NET without Windows – Matt Ellis
Functional web applications using F# and suave – Tomas Jansson
How to do a really good product demo – Katrin Grothues
Is your code ready for .NET Core? – Mark Rendle
Optimizing the Programmer: Get More Done Faster – Dave Rael
Sometimes the questions are complicated – Indu Alagarsamy
Agile Leadership – A trip through 2.5 million years – Louise Elliott
Go big or go home, scaling through caching – Harald Schult Ulriksen
Sunlight & Air: 10 Lessons for Growing Junior Developers – Erika Carlson
Website Fuzziness – Niall Merrigan
Have I Got NDC for You! – Mark Rendle, Carl Franklin, Richard Campbell, Dylan Beattie
C# Today and Tomorrow – Mads Torgersen
Python: An Amazing Second Language for .NET Developers – Michael Kennedy
Getting Into the Zero Downtime Deployment World – Tugberk Ugurlu
You don’t need JavaScript for that! – Ben Ilegbodu
Power to the people! – Tore Vestues
Making Komplett big by going small – Tomas Ekeli, Pavneet Singh Saund
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