As a SOHO (Solo Home Office) Developer one of the many challenges is the fact that there is no one else to discuss code changes with. Without someone to discuss changes with your blind spots will not be covered by a colleague looking at your code, potentially more bugs could creep into your code base and there are less opportunities to learn from other peoples experiences. So what can you do? Well here are some suggestions.
Recently, I wrote an article about a bit of a dust up in the AngularJS community about the plans for Angular 2.0 and it got me thinking about how we deal with the community - specifically when there is a widespread community backlash.
Collective responsibility is one of the artefacts of agile software development realized those days in many companies and teams (also called Scrum). When I talked with stakeholders about details of software project management strategies they are pushing forward – want to do, often I heard answer as “ask the team”.
It’s fairly self-evident that you need to have positive data points, but you need to understand that people will tend to view things in clusters. Once you know that, swaying perception (either positively or negatively) is an exercise in creating clusters.
I am under no illusions that this post will be the definitive explanation, but I spend a TON of time talking to people and level setting before I can have any kind of intelligent conversation on agile, so I want to explore some of the points that I think resonate.
Scrum is the most popular Agile methodology with Kanban a growing second choice. Learn about the core parts of each one as well as how they differ so that you can find the best fit for your team or organizational context.
The Weekend Edition is a list of some interesting links found on the web to catch up with over the weekend. It is generated automatically, so I can’t vouch for any particular link but I’ve found the results are generally interesting and useful.
Besides my personal perspective shifts, Southern Fried Agile was representative of a number of other perspective shifts ongoing in the agile community.
I don’t like to use the term smell. I prefer to say that you’re in “the valley”. I’m referring to the uncanny valley. When something looks and moves almost, but not exactly, like a healthy person, it causes a response of revulsion among some observers. To that, I believe there is an Agile uncanny valley and it’s full of Agile zombies.
Sometimes, you just need to get on with the work. You need to give yourself some breathing room so you can think for a while. Here are some tips that will help you tackle the day-to-day management work:
Last year, I wrote about how we use an agile approach for homeschool. Since then, we’ve refined our approach. This school year, we updated our board to reflect some of those changes.
In my previous post Agile Assessments, I wrote about reasons to do an assessment and considerations when doing one. In this post, I’ll continue the assessment topic with focus on Rating Scales and Frequency.
A post for those who want to see what an iterative, MVP-driven development of a feature looks like.
Our hard-wired need to conform flies against our desires to be different an innovative. As you consider strategy, you should make sure that you are not subconsciously shackling your ideas to the rest of the industry. But the good news is that because conformity is so popular, the few that are able to get past it end up in a remarkably powerful position.
During the post-conference drinks I was chatting with a developer - Matt from New Zealand if my memory serves - and he came out with what some might think was a surprising comment. He said: “I’d never thought of a project like that before.”
I was once told in a performance review that “perception is reality.” I was infuriated, and the words stuck in my mind as the most toxic thing a manager could say to an employee. Let me tell you what “perception is reality” means, and why you should plan on leaving your job the moment you hear it:
Make sure you didn't miss anything with this list of the Best of the Week in the Agile Zone (October 31 - November 07). This week's topics include working culture, technical debt, engineering humor, dialogue sheets, and career planning.
One of the more important things that you have to remember is that you should always be ready for failure. As developers, we are used to thinking about stuff like that in our code, but this is true for real life as well.
Most people are familiar with “technical debt” in terms of code or architectural problems that slow down development. There are other forms of technical debt, though, that can be overlooked.
I’m a believer that engineers not only need to act in a professional and ethical way, but they have to have a sense of humor too. For that reason I have the tradition to tell my class (almost) every semester week a joke or fun story with an engineering background. I have been asked to share the fun story from this week, so here we go...
This was a month ago at Perforce’s MERGE 2014 conference, but the videos are up now, so you can watch it too. Of many case studies that I have, I detailed one where a hedge-bet on the order of releases paid off. Not that the client knew they were hedge-betting at the outset, that’s just the reality of Trunk Based Development, Feature Toggles / build switches, and Branch by Abstraction.
It has been a while since I’ve written about Dialogue Sheets here - or indeed anywhere else. So here is a quick update and a request for some guinea pigs - I have ideas for new sheets but I need some teams to try them out.
As discussed in the previous post, a lot of developers move to management positions at some point in their careers. Now let's turn this around, instead of asking what is going on in the industry, let’s check what is going on with you. In particular, do you have a career plan at all?
The other day when I wrote about Vim and how to get started with it, I got a bit nostalgic with the editors I’ve been using over the years. Therefore, I thought I’d list the editors I’ve been using over the years. It would be very interesting and great if you’d like to share in the comments which editor you are using, and why you prefer it! Or with which editor you started your developer career!