I wrote a guest post on the Mashed Code Magazine blog, you can read it here.
I read an interesting article in the Wall Street Journal the other day about “Must-Have Job Skills in 2013″. While this wasn’t necessarily referring solely to technical fields, it was still interesting. Here is their list of must-have job skills:
- Clear communications
- Personal branding
- Productivity improvement
It made me think of the software craftsmanship people and the importance that they place on things like code katas, learning new languages, etc. If you’re a developer and you spend time honing your craft, how much value are you placing on skills like:
- Being able to write a good requirements document
- Facilitating a requirements gathering session with business users
- Giving demos of your software to users (in their language)
- Coming up with estimates for a large set of functionality
- Being able to evaluate tools and frameworks and choose the best one for your project
Admittedly, it’s much easier to practice TDD than it is to practice requirements gathering. But these are skills that I feel are very important for developers. There are lots of people who can write code, even good code. If I don’t know how to use a language or framework, someone can teach me pretty quickly and I’ll pick it up. But can you also pitch in and help with requirements gathering, test planning, system architecture and design, and everything else that needs to be done on a project? Now that will set you apart.
When you think about learning new skills and investing in your career, just make sure that you don’t limit that to tools and technology.
Time is one thing in life that will always remain constant. You can acquire more knowledge or more money, or you can save today’s money and use it tomorrow. But you only get 24 hours a day, and you can’t carry them over to tomorrow.
Most people would agree that there are not enough hours in a day. There are plenty of things I would like to do, books I want to read, projects that I want to work on, that I just don’t have the time to do. The challenge is figuring out how to make sure that you’re spending your time on the things that are important to you.
Know your priorities
If you don’t know what your priorities are, you won’t know how to prioritize your life. That sounds obvious, but it’s really hard to actually do. Many people don’t really know what their priorities are, let alone how to execute on them.
Do what’s important first
Something or someone will fill your day if you won’t. Personally, I hate the days where I feel like I didn’t get anything done that I wanted to get done because I was constantly reacting to things that came my way. Sometimes this is inevitable, but you can control it. For example, I expect that I should have at least half of my day available to do work (i.e. not stuck on meetings), so when a day is half full, I block out the rest of it so that no one can schedule me for a meeting. I do that because I need that time to accomplish what I feel is important and what people are expecting me to accomplish.
Live out your priorities
People are a priority to me, so if someone wants to go to lunch, I may or may not have time for that, but I usually go anyway and then find a way to everything else in around it. I have other friends who will go out of their way to make time to eat lunch when they’re really busy. That shows me something – that I’m valuable enough to be made a priority in their life. I love that.
My team is also a priority for me. This goes back to shunning meetings. I feel that in my current role, it’s more important for me to be with my team than to sit in a meeting with people from another team, so I block off my schedule and try to get out of meetings if I don’t feel that it’s valuable for me or the meeting organizer. (Sometimes people like to schedule 30 minute meetings for things that could be solved with a 10 minute hallway conversation.)
Own your life
I want to control my life and time as much as I can. I don’t want my life to control me because then I’m not able to do the things that I feel are important. The more proactive I am, the more likely I am to succeed at this.
I saw this in a job posting the other day, describing the work environment at the company:
We pair a lot, but not all the time. We test a lot, but not all the time. The key is being able to explain your practices with rational argument.
I love this. There are practices like testing that I hold in high regard, but nothing should be done all the time. As the posting says, “the key is being able to explain your practices with rational argument.”
Can you explain why you do something like TDD? That’s probably easy for you. But can you explain when you shouldn’t use that practice? That’s a little harder to do, and maybe because you’re holding onto some ideal that says you should test all the time or have 100% test coverage.
For every idea or practice that you find valuable, you should also be able to explain when it doesn’t apply. If you can’t explain when not to do it, I would say that you don’t really understand when and why you should use it.
I’ve talked about it for a long time, but I finally refactored my resume. I read a lot of resumes, and most of the time they annoy me because I get annoyed by the way that it’s written, even if the candidate is qualified. Yet my resume was more or less the same thing, so I figured I needed to take my own advice and do something about it. Here’s the thought process that led me to the end result (which you can see here).
Go to any tech conference and you get the big bag of vendor pamphlets trying to sell you their product or consulting services. These papers are very colorful and attractive and professional looking. What you don’t find is a black and white piece of paper with a list of 50 bullet points that enumerates their achievements.
We really are no different from those companies. We are trying to sell our services to potential employers or clients. So why aren’t we making our resumes look more like marketing material?
When I read a resume, I pretty much know whether I want to hire someone or not. The interview is just there to confirm my assumptions and potentially break the tie between two candidates. So if your resume is poorly done, you’re already behind the 8-ball before I even get to talk to you.
Answer the right question
Most resumes are answering the wrong question. The question to answer is not, “What did you do?”, the question is, “What sets you apart from the other candidates?”, or, “What experience that you have that can help our team/company improve?”
If you’re a QA person, don’t put “Entered bugs into bug tracking system” on your resume. That is something you did, true, but (a) I assume that a QA person uses a bug tracking system and (b) it doesn’t tell me anything about how you can help my team.
More is less
The way I see it, there are two kinds of people reading your resume. There are those who are briefly glancing at it to decide if they want to learn more. There are those who want to learn more and/or interview you and they will read more of it. No one ever reads it all.
With that in mind, only put things on there that you want someone to read. I know that sounds obvious, but apparently people are not good at it. You want to make it easy for the people glancing over your resume to want to read more, and you want to make it easy for the people doing the interview to find what’s important.
Everything on your resume has a value — but that value can be negative. When I read a resume before an interview, I read through the last couple work assignments and cross out everything I read that doesn’t add value. Then I’m left with the statements that have value. I would’ve much rather just read the good stuff without having the black out all of the cruft.
Also, I don’t really care what you did in 2003. Chances are you were using a technology that is not the technology being used in the job you’re applying for. Just tell me the things that have relevance, either because it’s a similar skill to what the team needs or because it’s something that you did relatively recently.
No more than 2 pages
I’ve never found anything meaningful on page 3 of a resume, so don’t have one. You don’t have to list every place you’ve worked and you don’t have to list every single thing that you did there. This is particularly challenging for consultants because we tend to move from project to project. Remember, you just have to give me enough information to make me want to work with you, you don’t have to tell me your life story.
Write it so someone would want to hire you for the job you want
If I think about my ideal project, it would probably involve Agile, TDD, either .NET or Ruby on Rails, and working in a team environment with people who care about their craft. I tried to make my resume reflect that. On the first page, I highlight how I’ve led Agile projects, I do TDD training and like unit testing and acceptance testing, and how I’ve used Ruby on Rails and ASP.NET MVC, which is my .NET tool of choice. I put a link to my GitHub account because people who tend to think like me like to see that developers hack on stuff and like to be able to look at actual code they’ve written. I also have a link to my blog so that people can learn more about the things I like (and don’t like). While I don’t claim to be great at design, I’ve tried to add some flair so that people can see that I am creative and am capable of thinking outside the box, which I think is an important quality for a software developer.
I actually went through this process when I created the first page of my resume. I made sure I highlighted all of the important stuff that I mentioned and left off everything that was not on that list. There’s room on page 2 for the other less important details.
Things I don’t want to do are nowhere to be found on either page. I’ve done C++, WebForms, and TFS build server administration. I really don’t want to do those things again if I can help it, so I’m not going to list those things anywhere. The people hiring someone for my ideal job wouldn’t care about those things.
You are selling yourself. There is nothing that mandates that your resume be a sea of bullet points or that you must list everything you’ve ever done. You are much smarter than that, so be creative and come up with your own marketing material. Then walk into the interview knowing that they have the important information they need to want to give you the job.
I came across this post the other day that went on and on railing on things that the author found unacceptable in today’s web frameworks, specifically Rails and ASP.NET MVC. It covered the whole gamut of issues, from abstract base classes in ASP.NET MVC to mega-controllers in MVC frameworks.
I’ve thought a lot of the same things too, to various extents. For example, I’ve never understood why controllers existed. Why can’t we just define routes that are handled by route handler classes that use conventions and REST and things like that? Yet I continue to use controllers in web apps. It made me think, at what point is something bad enough to do something about it and when do I just live with it?
This is the kind of question that makes software development so difficult, but at the same time a lot of fun. Today we were looking at a piece of code that needed to be refactored. We couldn’t figure out what the right way was to implement it, nor could we decide if it was worth the time to even do anything about it.
How do you decide what to do in this situation? The way I see it, you have to look at the return on investment on everything you do. In my controller example, I could invest the time to implement some non-controller solution. On a large enough project, I would probably get a good return on investment compared to using controllers.
But then again, you could argue that since controllers are towards the outer layers of the stack, maybe you can live with it. I care much more about the sanctity of the domain model because that’s the heart of my application. So is it really worth the time or not?
But it gets more complicated than that. Let’s say it takes me a week to implement the non-controller solution. During that time I’m not delivering any client facing features, and that might not sit too well with the people paying for your project. I was in this situation once, and the project almost got cancelled. Thankfully I pulled it out and was on the project for a year and a half and my framework investments more than paid off. But those first few weeks were nerve racking.
So what’s the answer to my original question? I guess it depends. As does pretty much everything else in software development. Which means that you don’t get an easy way out and you are going to have to use your head.
I still think I’m right about the return on investment thing. But at the same time you need to be shrewd about it.
A recent post on a local user group message board set off a firestorm of reaction. The gist of the post was that developers in Columbus “seem to focus on life in their work/life balance”, aren’t interested in working long hours, “check out at 5pm”, and that “the drive to put a dent in the universe doesn’t seem as strong here.”
Steve Jobs is the poster child for the startup/work hard lifestyle. Steve Jobs worked really hard, made a lot of money, and invented technology that changed the way that many of us doing things. When he died, scores of people were proclaiming his greatness and praising him for his contributions to society. According to many people, Steve Jobs made a large dent in the universe.
I hope I’m making a dent in the universe. But if I am, it’s not going to be because I write code. I’m thankful that I get paid to do something that I really enjoy doing. But at the end of the day, what difference does it make if I write some code that helps a company make more money?
Obviously I’m not living in Africa running an orphanage and digging wells for poor people, but doesn’t mean that my time spent writing software is meaningless. I’m reminded of the scene in Chariots of Fire when Eric Liddell is talking about how he feels when he runs.
I believe God made me for a purpose, but he also made me fast. And when I run I feel His pleasure.
Eric was a missionary to China at times in his life, but he also found a lot of meaning in training and running in the Olympics. Some people said that running wasn’t as important as being a missionary, but running was a means to an end for him, that end being finding God’s pleasure in whatever he was doing.
We’ve all been given talents, and many of us use them every day at work. I hope that my ability to write software will give me opportunities to make a difference in lives of people that I encounter in the process. I hope that I can install confidence in the people I work with and that we can build camaraderie while we work together towards a common goal. I hope that people are energized and excited to come to work and that we can experience that good feeling that comes with working together to be successful. And while we’re at it, we’ll develop some software that will help a business be more profitable.
While I enjoy what I do at work, to me there’s a lot more out there for me than my job. I’m just not willing to line up for 80 hour weeks, multiple side projects, and lots of weekends away from home. I have a wife and two kids and to me, those things are much more important than software development. This doesn’t mean that I’m not dedicated or that I don’t care about my craft or that I’m any less of a developer than the hero programmer working 80 hours. I just have some other priorities in life that I also find important.
Many people out there work long hours (particularly people who are single). Many doing it willingly because they enjoy doing it or they find it challenging and exciting. I don’t really have a problem with that, because we’re all entitled to spend our time doing what we want.
If you could promise me that if I worked as hard as Steve Jobs that I would have the level of success that he had, I wouldn’t take you up on it. I guess I just have a different view of what success is. I would rather be a good husband, father, and friend to other people and try to use my job and career to further those goals. I may not appear to be as “driven” or “motivated” to people in the startup world, but I beg to differ. I have a passion for what I do, and software development is just one piece of that puzzle. Go on vacation away from your computer and your job for a week and you’ll notice how it doesn’t seem so important by the end of the week.
We are fortunate as developers to work in a fun and exciting industry where we get paid to do something that many of us would enjoy doing for free. My challenge to you is to look past that and see the big picture. Some day my working days will be done and when that time comes, I have a feeling that I will care more about the friendships I made and the people I helped than I will about whether I followed the Single Responsibility Principle or how many user groups I spoke at. But that day is still a long way off, so for the time being I’m going to use all the passions and abilities that I’ve been given to make the world a better place.
UPDATE: Apparently someone else was thinking the same as me… and it’s worth the read.
DISCLAIMER: Nothing said in this post should be taken as a reflection of my relationship with any of my employers or clients, current or in the past. Thankfully the ones I’ve had have been pretty good.
How do you view your relationship with your employer? More specifically, what is your response to your employer’s requests and demands?
I feel that many people view the relationship with their employer like a sort of indentured servitude where you also collect a paycheck. When I say that, I don’t mean that in a negative way, because most people don’t think of their manager or employer in a bad light. But I feel that most employees feel like they should do whatever their employer asks them do without raising a fuss (unless something they are asked to do is unethical). Again, I’ve thought this way in the past, and I never really thought of my employers negatively (in fact, I really liked them).
The Business Of You
Today I would argue that this is not the correct way for you as an employee to view this relationship in most cases. (Yes, I am an independent consultant, so I don’t really have an employer, but I still work for and report to clients.)
Business have all kinds of relationships without outside vendors. For example, a business may have preferred hardware vendors, vendors that provide hosting services, vendors that provide janitorial services, and so on. These relationships are all mutually beneficial partnerships, where each side of the partnership has something to gain from the relationship. Businesses also have partnerships with software developers like you.
Whether you think of it this way or not, you are running a business. Your business sells your software development services. You have a business plan, goals, a balance sheet, and things that you value (you might not have these things written out, but you still have them). Your values for your business might be to make a certain amount of money, to work using a technology you enjoy, to feel like you’re making an impact on the company you work for, have time for whatever hobbies you like to do, and have ample time to spend with your family. Your family is also a part of your business because they are something that you value, and what happens at your place of work affects them too (either directly because you’re gone at work or indirectly because you’re stressed out when you get home).
I think you might view your relationship with your employer differently when you view it as a partnership between businesses. Businesses and vendors negotiate all the time on any number of issues (and not always related to money). If you think of it this way, instead of your employer unilaterally deciding the path for your business, it should be something that you both agree upon that is mutually beneficial for both sides.
Protect Your Business Interests
Like I said, I’ve had the good fortune of working for good people throughout my career, but unfortunately there are employers and managers out there who will try to coerce you into do things that are not in your best interest. For example, maybe you’re heard things like these from your manager:
- “We have a lot to get done this release and we can’t afford to hire anyone else right now, so you all are going to have to work a little extra to get this done.”
- “I know that I told you to build the feature that way, but actually it needs to work this way… but I still need it done by the same date.”
- (a few days before a release) “This feature just came up and we really need to get this in, I’m going to need you all to stay late to get this done.”
Overtime, while not ideal, is a part of what we do. There are going to be deadlines, server outages, and things like that. But there’s a difference between normal overtime (server outages happen and someone needs to fix them) and someone taking advantage of you either for their own benefit or because they don’t have the guts to say no to their superiors.
Every situation is different, and maybe you’re OK with these sorts of requests. Maybe you get paid overtime and you like the extra money. Maybe you are willing to go the extra mile to get ahead or get a promotion, or maybe you don’t have many other job opportunities out there so you have to stay and deal with it. Maybe you’re in a job where overtime is expected and you knew that going in.
The important thing is to think of your career like a business. If you’re employer is trying to get you do something that isn’t good for you, don’t just sit there and let their decisions drive your business. This also applies if you want to work with a certain technology or skill set and your company doesn’t have that kind of work for you. Be willing to say no, or even be willing to go find another job. Your career should be something that benefits you and benefits the people that you work for, and as soon as one side isn’t getting any benefit, then something needs to be done.
I spent my lunch hour at the Path to Agility conference talking with a friend of mine who is in the middle of trying to get his team to embrace some agile practices, particularly around automated testing. Some of the changes that he’s trying to implement are causing some friction with the team who are not embracing the change.
People not wanting to change is nothing new. But what is the reason behind that unwillingness? It’s real easy to blame the team members and just say that they don’t care, they’re lazy, they like technology X instead of the new thing, etc.
Instead of just blaming others, maybe we should look at how we (as the change facilitators) are helping to create a desire to change and an awareness that there is even a need for change. If you’ve been doing your job a certain way for the last 10 years at the same company and you’ve been getting praised for your work or getting good performance reviews and raises, why should you change? After all, your company has been telling you that you have been doing an exceptional job. And now you’re being told that the way that you’ve been doing it is wrong?
This is what makes situations like this particularly challenging. Before we can even expect people to change, we need to show them that although they have been doing a good job in the past, we have an idea of how they can do their job even better. For some teams, having 50 bugs in production each month might seem good to them if last year they had 80 bugs in production each month, when for some teams having 5 bugs a month in production is a lot.
Unfortunately there is no easy answer to this problem. In fact, I can’t even say that I really know how to effectively handle these things. What I am learning is that the people side of software development is probably the most difficult part, and it’s probably where we all need the most work.
Older Posts »