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
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
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.
There’s nothing like being able to work on a project by yourself and having complete control of every single aspect of the solution. Everything from the front-end stack to the storage. Using the latest and greatest frameworks and libraries. This is heaven for any software developer. But regardless of any of the above technology-focused aspects, there is one major advantage being that single developer, namely: speed! But there are pitfalls when writing software alone. Continue Reading
Firstly, thank you for taking the time to visit and read this blog.
As software developers we are challenged throughout our careers to deliver great code that accomplishes something valuable for someone. Sometimes that someone is yourself. Other times it could be a customer, end-user or even other developers. All have in common that there is a need that has to be solved and you as a developer have the capability to meet that need. Continue Reading
