thoughts on coding and everything in between
Category Archives: Uncategorized
Time To Go
“We’ve sold the company and over the next few days we will be helping everyone find new opportunities.”
This is not a statement anyone wants to hear at a company meeting. This year, I was one of those employees. It left many people scrambling to make themselves more marketable in just a short amount of time.
Developers were (thankfully) already in high demand and thanks to some terrific leadership, everyone was more than marketable – in some cases we were too relevant as many of us were soon to find out.
But I didn’t just want a j-o-b, I wanted to enjoy my work and look forward to going to work every day (or at least most days!). I wanted to work for a company that I could respect and that respected me & my abilities. I wanted to work in a place that I could help make a difference, improve processes, and participate in making the company great. I wanted to work for a place that would challenge me to think smarter, not harder, and would set me up for further success in my career.
Less Than Appealing
A person looking for a job very rarely has the opportunity to be picky. After all, no one (and no company) is perfect, but there were definitely some interviews where I tried not to run back to my car or hang up mid-sentence! As a prospective employee I was prepared to be a good interviewee, but I certainly was not prepared to be poorly interviewed. I have had the privilege of sitting on both sides of the interview desk but I wasn’t prepared for those who interviewed me to do a bad job.
After being back on the interviewee side of the table again, I have a few recommendations for hiring managers:
- Remember the person who you are interviewing considers time a valuable resource just like you do. Don’t assume that just because they are looking for a job that they have all the time in the world to wait on you or shoot the breeze. If you say you are going to do a 30-45 minute phone interview, don’t let it run into 1.5 hours. If your procedure is to have an interviewee take a test, have the test prepared ahead and make sure an appropriate amount of time has been allotted and communicated for both test and interview.
- Be honest. Do a reality check of your environment and team. Be prepared to share honestly what your interviewee will be getting themselves into if you decide to hire them.
- Include a couple of the people who may be on their team. This is another way of a reality check for both you and the interviewee. It also lets your team know they are valuable and that they will be an important part of the successful addition of a new team member.
- If you start with a phone interview, make it useful. Fifteen minutes of “do you like to code?” or “what do you think you want to do” is not helpful or informative to you or the potential new hire. You both should be able to get a good sense of whether or not it will be a waste of time to conduct a face-to-face interview.
- Pay attention to the right details. You might think all hiring managers are attentive to the details, but that is actually not a genetic trait of managers. You need to know what the interviewee expects from this job (pay, start date, benefits, etc). There’s no need for them to beat around the bush – it is a factual part of a job and one that shouldn’t cause surprises to either party. It is even more important to notice behavioral details. Just because someone “knows” thirty programming languages or they passed your test with flying colors doesn’t make them an automatic hire or the right fit for your team or organization.
I have been very fortunate to be part of a great leadership team I can very proudly say that we almost always did these five things (nobody’s perfect!). However, through this process I have seen more than a few hiring managers not do one or all of these and they have paid the price (as have some of their new hires).
Not The Only Ones Responsible
As a prospective employee, I worked hard at making sure the person interviewing me had no reason to dislike me and even the interviews that I couldn’t wait to get out of I did my best to make the interviewer feel good about having me there. I would not ever recommend that someone looking for a job do anything different. However, you definitely need to be taking mental notes & know what clues are being given that will help you love it or not.
As an interviewee, here are the things I was (or should have been) looking for:
- Are they prepared? I’m sure sometimes this is a tactic used by managers to test a stress reaction, but I actually think that is poor leadership. A good leader should be displaying the kinds of behaviors they expect from their employees. “Attitude reflects leadership, Captain” (Remember the Titans) If you want to be an excellent employee, don’t go to work for someone who doesn’t lead you in that direction.
- Are they using current technologies? It doesn’t have to be bleeding edge, but if the company is going to move forward they will have to be keeping up with current technology. If cost is the excuse, then consider how they might look at paying you. If time is the excuse, then consider the schedule you might be expected to keep. If they don’t have time to ever do things the right way, that indicates poor time management & unrealistic deadlines. If the reason is “That’s the way we’ve always done it.” then consider if they will be able to sustain growth (including your own) and if they will really care about your ideas.
- How do they treat or view their current staff? If there are a lot of secrets to bringing you in, then consider how often you will be communicated with. If they talk down about the staff they have (especially if they are saying how great you are in comparison) consider how they might talk about and think about you when you’re not around. Do they invest in their teams & the workspace? Do the other employees connect with one another regularly about non-work things? You will be spending approximately half of your week there so consider the affects the environment will have on you.
I’m sure you can come up with more things to look out for as well, but of course during the entire interview it is never a good idea to give them the impression that you don’t want to work there. You never know, you might wind up with no options for the time being, so don’t shoot yourself in the foot.
Keep A Sharp Eye Out
Regardless of whether you stay or leave a company and regardless of the reasons why, these are always things to keep an eye out for because people and companies are always changing. Make yourself an excellent employee and expect excellence from your leadership.
Code katas are not a new concept at all, but my recent participation in daily katas has compelled me to consider how valuable they really are.
I won’t bore everyone with the technical definition of what a kata is; a kata is basically a specific thing you do repeatedly in order to improve in that area.
For me, no matter what it has been that I have had to practice (studying, playing the violin, coding, etc) it has always been painful & difficult, especially in the beginning. But that’s kind of the point isn’t it? If it were easy, then I wouldn’t need the practice. It seems to me that there are some people out there for whom certain things just come naturally, but, as tempting as it may be, we can’t let ourselves get caught up on the abilities of some in such a way that it distracts us from using regular practice to improve ourselves. Instead of comparing our abilities (or lack thereof) we need to just work hard at getting better if we really want to be good (dare I say the best we can be?) at our craft.
Maybe you stumbled upon this blog post because you don’t know how to do a code kata, or because you need some encouragement continuing in katas, or perhaps you have lost all interest in regular, consistent practice – here is just a bit of advice I would have given myself before my first code kata:
1. Don’t quit & don’t make excuses. Sure, it will be hard and frustrating (or boring) sometimes, but the point is to get practice – that’s it. So just do it, and keep doing it.
2. After coding a problem kata to its solution, scratch it and start over from the beginning. You just might come up with a better way to do it or if nothing else, you will get practice with how quickly you can put it back together again.
3. Code kata for a maximum of 30 min. Keeping it in short sprints will help you get faster, it will force you to get & stay focused, and also gives your brain a break & a chance to work on something else.
4. Do a code review after you are done with your practice time. Have a co-worker or colleague open your solution and talk through what it is doing. Having to be accountable for the code we write helps us to learn and keeps (or makes) us humble.
5. Try something new – a new problem, a new language, a new code reviewer, no mouse – anything to mix it up and stir up any area that needs improvement. It is also a good way to avoid boredom.
6. Take constructive criticism and learn from it – let go of anything else. Constructive criticism seeks to teach you the better way, but any other negative or derogatory remarks or feelings do nothing to help you out so learn & move on.
7. Don’t be intimidated by the exercise. Don’t feel like you should know it all right away – that defeats the point of the kata. Of course you won’t have the best solution right away. We practice so we can learn and get better.
For those of you who want to continue improving your development craft here are a few kata websites my team and I have used. If you know of other sites, please share them – or come up with some of your own! Happy coding & good luck!
You’ve heard of group-think? The “tendency of the members of a group to yield to the desire for consensus or unanimity at the cost of considering alternative courses of action.” (http://www.businessdictionary.com/definition/group-think.html)
I think in the world of software development we have to be careful not to engage in “developer-think”. What I am calling developer-think I am going to define as the tendency of a developer or group of developers to disregard effective and real value-added design and development for the sake of what makes sense to them.
When presented with a new project, it can sometimes be challenging for the developer to stay focused on the task at hand. Mind you, I am not saying that features should never be added to the project! If the feature can be added without costing more than the value added it could be considered. However, if the developer wants to add the feature to increase the coolness factor, or to make it conform to a particular coding practice, or to just blindly do whatever the user requests, it would be better to leave it alone or at least give it some additional thought time first.
My boss actually has a very realistic point of view here “The faster you can get your project released, the less time the customer has to come back with questions or changes that will put the project behind schedule.” I think more developers should think that way! There can always be a phase 2 or 3 or whatever, but a project that is scheduled to take three weeks that turns into six months has some serious issues! Before you pass the buck, consider that it very well may be due to “developer-think”: not understanding the end user’s needs and requirements, over complicating a solution, feature creep without value added, and I’m sure we could think of more!
Some developers are very intelligent people who develop brilliant pieces of code in only a few hours. These brilliant developers, if not careful, can add complexity, and within a group who respect and admire their work, those same brilliant developers can easily lead the entire group into developing a security access application for a nuclear power plant instead of the requested simple login screen for a blog (just example).
Some developers are so focused on thinking analytically and logically they forget to think about the way the users leverage the application and in the worst cases of course, completely and purposefully disregard the users. But they don’t seem to remember that without the user, they just have an application that no one uses! I have been in places where users didn’t want to have anything to do with the developers or anyone in I.T. and as a result the projects are either very difficult to complete or hold no interest what so ever. Everyone who wants to work in that environment raise your hand! No takers? Huh. Maybe we should treat our users as a valuable asset to our work. For those developers who don’t like users, maybe its time to take this sage advice (slightly modified) “Keep your friends close, and your users closer”.
A third pitfall developers fall into is adopting a “cool” new coding practice without counting the cost. We have all read or seen something new and cool that either would make our lives easier or would be awesome to implement in our current application. Sometimes, with the right project and the right time allotment, we can actually implement some of those enhancements. However, the danger is in getting off target and making the project run a little late (or a lot late). This could lead to more time for user feature requests, open the door for visible possible enhancements, or just simply slow down the work of your team. Again, sometimes its worth it, but the cost needs to be counted first. In a good, agile shop, developers should be ready to release early, release often, and continue to keep the projects moving forward.
A good group of developers recognize these behavioral tendencies within their group and will work together to help each other stay away from these pit-falls. How can you tell if your team has succumbed to “developer-think”? Start with some of these evaluative questions: How agile is your shop? How long does it take you to release a fully tested medium-to-large sized project? What is your relationship like with your users? Do they value you or talk bad about “I.T. people” every chance they get? If those questions can be answered positively, you are probably on the right track already, but remain vigilant and keep them positive.