In February of 2001, seventeen people gathered at Utah’s Snowbird lodge to discuss software. They were a diverse group, some with competing interests, some of whom admitted that it seemed unlikely that they would “ever agree on anything substantive.” While many of the concepts that emerged as the Agile Manifesto were not new concepts to those who attended the gathering, the distillation of the ideas into something substantive that was valued by them all was monumental and has become a beacon of shared values that have started to transform our industry.
The concept of Agile has been disruptive to the industry — and that’s a good thing. Every industry has gone through serious evolution over time; just think of how things have changed over the centuries in the areas of home construction, science, and health care. By the late 90′s, our industry had become entrenched in practices that needed disrupting. And yet, many of you have probably noticed that not everyone welcomes Agile. My experience has been that interest often begins at the developer level (or even developer management level). And then acceptance of the idea is mixed from there. Of course, acceptance among the development team can also be mixed depending on the chosen methodology and how well it blends with the members of the team. It seems that Agile is most effective when the company management finds value in it, drives Agile adoption and embraces the culture change that brings to the company.
So you’ve sent your newly polished resume in for that perfect job; now what? In this excerpt from John Sonmez’ new course Preparing For a Job Interview you’ll get an overview of a common interview process and tips on how to make the most of each step in the process. In the full course John covers how to build a good resume, and also how to handle many of the technical and computer science type of questions you may encounter in your interviews.
There isn’t a large amount of advice out there on developer job interviews. I’ve found that many talented developers have difficulty with job interviews, because they spend more of their time focusing on what they are truly passionate about, technology and development, and not much time prepping their interview skills.
It’s unfortunate, because having good job interview skills can really help you advance your career by giving you opportunities you wouldn’t be able to get without being skilled in this area.
1. Hire an expert to create your resume
I’ve mentioned this idea before, but it is so important that I’ll say it again. Unless you write resumes for a living, you are not a professional resume writer.
There are people who write resumes for a living and those professional resume writers probably don’t try and write their own software to use on their computer.
So, if resume writers don’t write software, why would software developers try and write resumes?
Some years ago I started writing occasionally in a genre that I call the “Soft-boiled detective techno-thriller parody”. It’s been a while since I’ve written one – I hope you enjoy it.
The Southwest flight to Salt Lake City was turbulent, mostly due to the terrified shudders of the passengers with peanut allergies. I was trying to rest my head against a new parka that I got at half price from Macy’s, wondering what a nice Silicon Valley boy like me was doing heading to the icy reaches of Layton…
It started a few days earlier. I was sitting in my office – I’m a PI – Private Investigator – working the streets of Silicon Valley from the hipster neighborhoods of San Francisco, to Sand Hill Road, to the hills of San Jose where rusted signs on fence posts point to the future of software development.
A creaking sound from the stairs announced my next clients. From the sound, I knew they were real heavyweights. They didn’t bother to knock.
The guys were big – muscle. The kind of guys you don’t mess with. I was about to reach for the gun I keep in my desk drawer, but one glance from the leader told me that would be a bad idea.
While it might seem a bit paradoxical to think that there could be such a thing as a “good” failure the fact is that some failures lead to better code, better developers, and ultimately a better product. On the other hand, some failures are only “bad” and lead to nowhere particularly pleasant. It helps to know which failures to fear and which to embrace, but of course first you have to be able to tell the difference.
The primary difference between good failures and bad, are the actions that arise as a result. If for example, you have a significant defect in production that causes panicked late night meetings, emailed threats from management, and teams overdosing on NoDoze then it’s easy to get caught up in the frenzy to fix the defect and forget that this is an opportunity to learn. Sure, after the fire dies down and the executives all move on to other catastrophes you might do a root cause analysis and there may even be actions to take afterward. But many times without the intensity and focus that the defect caused even the best of intentions to improve can get lost in apathy and a “business as usual” mindset. That failure becomes only bad, leading to no improvements.
Doug Seven, former Visual Studio Director of Product Management and now Executive VP of BlackOps at Telerik posted a great description of the differences between strategy and tactics in the art of product management. Along with defining the difference between strategy and tactics he also points out the importance of measurement as a tool to evaluate a strategies effectiveness as well as how to create a strategy.
“The difference between strategy and tactics is the difference between a plan and an action. A strategy is the plan–an adaptable plan–for how you will achieve a goal, and the tactics are the executable actions you will perform to achieve the result outlined by the strategy.” - From Doug Seven’s Blog
Doug goes on to describe the steps involved with creating an effective strategy whether it be for a business, product, or person. Starting with a clear vision is key and will lead to creation of strategies designed to “change the system”.
Nick Malik posted an excellent blog post as a result of viewing several sessions during the Open Group Conference that had him ask how we decide what constitutes a “Best” practice. In the blog post he describes the difference between agreement on the suitability of a practice and the labeling of that agreement as “Best”.
That said, as much as Jeff and I agree, our agreement does not mean that the practice should be considered a “best” practice. Who are we to say? We are practitioners. While that is good, it is not enough in my mind to qualify the practice as “best.” – Nick Malik’s Blog
Being a developer takes more than skill with today’s technologies, you also have to have your eye out for tomorrow’s as well. In this video excerpt from Dan Appleman’s new course Career and Survival Strategies for Software Developers you’ll get an understand of why the software field is different from other fields and the importance of having an education strategy. In the full course Dan covers other key career management concepts such as the software developer lifecycle, getting a job, and establishing your brand.
Getting things done has always been a challenge regardless of gender, age, race, skill, or job position. No matter how hard some people try, they end up procrastinating tasks until the last minute. Some people simply focus better when they know they’re out of time and can’t procrastinate any longer. How many times have you put off working on a term paper in school until the very last minute? With only a few hours left your mental energy and focus seem to kick in to high gear especially as you realize that you either get the paper done now or risk failing. It’s amazing how a little pressure can turn into a motivator and allow our minds to focus on a given task.
Some people seem to specialize in procrastinating just about everything they do while others tend to be the “doers” who get a lot done and ultimately rise up the ladder at work. What’s the difference between these types of people? Is it pure laziness or are other factors at play? I think that some people are certainly more motivated than others, but I also think a lot of it is based on the process that “doers” tend to follow – whether knowingly or unknowingly.
When did our industry make the transition to one where foul language, off-colored women-demeaning jokes, and illicit drug glorification became a respectable and celebrated medium for talking about software practices? Did I miss something? Perhaps an announcement or white-paper suggesting the new appropriate way to present to our industry?
I attended the software craftsmanship conference in Chicago in November, and while I enjoyed the conference and found most of the talks very enlightening, I was disappointed with the pervasive lack of professionalism. Apparently the F-bomb is the new vogue for software craftsmanship because it seemed like about every third speaker felt it necessary to scatter it throughout their presentation. Also prolific was the inclusion of hard-core drug references. I didn’t realize that was an important part of software craftsmanship. I recognize that this conference is less formal than some, and a noticeably smaller group than others, but I wasn’t the only one who was dismayed by the nature of some of the talks.