Tag Archives: software

When To Quit Your Job

A friend asked for my advice on this subject recently:

I’m kind of thinking about changing jobs. I’m doing good at [COMPANY] so no concerns there. I would honestly rather be working in the software and technology space, instead of the financial industry. […] The other factor is that I’m not in an area where I can attend conferences and be involved in a good development community. I’ve only been at [COMPANY] for [less than 12] months. What do you think?

While I was flattered to be asked for such personal advice, I’m not really qualified to say what’s best for anyone. Maybe not even myself. Remember this.

The following is the philosophy that I try to follow in terms of changing jobs in case helps anyone.

When To Leave

First, as anyone I’ve talked with about this will tell you, I’m a big proponent of changing jobs at least every 3-4 years.

Departures

In our profession, this helps us remain fresh and exposes us to new tech/architectures/ideas in a way that is hard to ignore. This is a good thing. My general rule holds unless there are special circumstances. For example: vesting concerns, when nearing retirement, or another important life event. I’ll also interview every year or two in order to keep my interviewee skills honed and because it helps me to be a better interviewer when I’m performing interviews at my current company.

When To Stay

As for a shorter end of the tenure spectrum, I usually will stay a minimum of 1-2 years.

Again, this is a rule of thumb. I’m not going to cover all of the exceptions here. If circumstances like a hostile work environment or an amazing new opportunity came up, I would consider breaking it. I have a friend who left a company after a couple months once because it ended up being hostile. I can’t imagine any decent future employer who would fault him for this. However, it is the only instance like this in his career. An established pattern of “hostile” work environments is a read flag all by itself.

If you are making an immediate decision, sleep on it. One more night can help organize your thoughts and shouldn’t hurt anyone involved.

Regrets
Don’t make a hasty decision you might regret.

As for my recommendations, the first year is basically for resume purposes… taking a full-time employee position and then quitting before a year is up might make some employers question the value of going through the cost and effort of bringing you on. It may even be “interview prohibitive”.

The second year and beyond is often when I find that I learn the most about a business, can contribute the most (due to knowledge, trust/influence earned). It is also when I solidify relationships with people I work with.

Contracts

MercenaryAll of this is basically thrown out the window for contract positions. Contractors are expected to be mercenaries, to an extent, and might switch companies/projects every month without much scrutiny. I think there are some interesting things to be learned from that as well but I don’t have a lot of personal experience. I’ve considered joining a firm similar to Catapult or StG that sends contractors out to multiple companies and has a bench program for downtime. I believe it would be a valuable experience.

Summary

So the short version is: except for contracts, aim for a 1-4 year stay whenever starting a new job. Commit to this mentally, or don’t accept the offer. An exception could definitely be made in either direction under the right circumstances, but don’t plan on it. In practice, I have stayed at each of my gigs for 2-3 years without exception.

In my friend’s case, his company/team doesn’t match the values he wished they had and isn’t working on anything terribly interesting. Also, he is considering leaving the area. Not an emergency per se, but not great either.

My advice to him was to stick it out until a year is up while doing his best to influence change at the company. If things don’t start to improve in that time-frame, (i.e. if he felt he wasn’t having a positive impact) start looking.

Again, I’m not really qualified to advise anyone on their particular situation. I do believe these ideas have value and should be discussed.

 

Legacy Dependency Killer

As promised, here are the slides for my hands-on coding session at Utah Code Camp. Thanks to everyone who attended the session. I had a lot of fun and I hope you did as well.

Also, the code is on Github: https://github.com/KatasForLegacyCode

I’d love to get it translated into Java, C++, and any other language that would be reasonable. I could probably do either of those myself, given past experience, but it’s been so long I couldn’t guarantee that the code I produced wasn’t legacy as well. If anyone is interested in helping out here I’d be very appreciative.

Hopefully, I’ll be creating other katas for legacy code in C# using other common patterns and publishing them here as well.

I Like Food

Hopefully this article isn’t as banal as the title suggests. “I like food” is what I say when someone in the office asks me to join them for lunch (usually).

Why?

food-question-mark-628x363

 

Because I like my teammates? Sure.

Because I’m hungry? Usually.

Because I like food? Also true.

Because want to enhance my relationship with my coworkers and build camaraderie among the group? Getting warmer but not quite. The familiarity that comes from knowing someone outside of work does tend to humanize them and help with relationships and camaraderie (and all those touchy-feely things we engineers aren’t supposed to care about because we’rerobotswhoonlyknowhowtowritecodeanddrinkmountaindewandurinateinemptybiggulps).

In my experience, the real benefit is in improvements to communication and cohesiveness. It’s in the ability we gain to understand each other as people, to know our strengths and weaknesses, to use shorthand in communication, to avoid causing or taking offense, and to just be more effective working together. Whenever possible, I like to participate in non-work activities with my brothers-and-sisters-in-code (and sometimes with others at the company as well) because it makes us more effective. Good companies/managers understand this concept and go out of their way to engage teams in “teambuilding”. This can be a dirty word in the wrong environment. Don’t work in that environment!

ready_to_eat

So unless I have an important errand to run or previous plans, invite me to lunch. I like food.

Software Prototyping: Please Throw This Away

I believe in the value of prototypes.

So do manufacturers, designers, and silicon valley. New hardware concepts at large coprorations like Google, Apple, and Microsoft are accompanied by many prototypes (for example Google Glass).

prototypes

User interface prototypes are key to discovering usability and are commonly used by designers. Often this starts with pen and paper before a single mouse is clicked or keystroke registered.

uiprototype

One similarity shared by all prototypes I want to mention before continuing is this: prototypes are never meant for use by the end user. In the case of Agile software development, we may have a select group of users work with prototypes with the knowledge that they will never see production usage in their current state. Additionally, if a piece of software serves some purpose in a production environment, it must be developed as such.

Opinions will vary on this subject, but here are the most important traits of a software prototype in my opinion.

  • A software prototype is developed in isolation. No (or absolute minimum) interaction with existing code.
  • A software prototype follows coding standards. We write clean code regardless of its final use. Perfect practice makes perfect results.
  • A software prototype is written by people who are constantly learning and training to hone their craft. More on this later.
  • A software prototype is written by people who will be responsible for writing the finished product.
  • A software prototype is discarded. I repeat. Throw it away after demoing it.

When the above specifications are followed, we gain some specific benefits.

  • We are provided the opportunity to experiment with a few of the myriad different solutions to a given problem.
  • We have the opportunity to learn from mistakes before creating a production-worthy solution.
  • We have the opportunity to use the best design possible based on first-hand knowledge when creating the final product.
  • Product/business people see their concepts in action earlier in the software development lifecycle.
  • Other groups/departments aren’t paying people to learn to develop software they aren’t ultimately going to create.
  • The company enjoys faster overall development times as technical debt remains low.

everyoneWins

My continued belief is that many companies have a large disconnect between technical and business people on the purpose and value of software prototypes. Prototypes are as much for developers and engineers as they are for business and product people. Technical teams should own prototype implementations.

Guide To Developer Training For Managers

Developer training often neither begins or ends in the classroom.
Developer training often neither begins or ends in the classroom.

First things first, why on earth would you want to train developers? Isn’t that just an added expense? This is a fallacy for a several reasons including the fact that:

DEVELOPER TRAINING DOESN’T HAVE TO COST ANYTHING

More on that part later!

Development training and continuing education is vital to companies that want to maintain a healthy and satisfied development group. When we opt to invest in training, we are choosing to ­­retain valuable specialist employees and to teach them to be more effective at what they do. This has multiple benefits for the company and the employee:

Efficiency/Simplicity – Employees become faster, more efficient, and make fewer mistakes when they have hands-on training in best practices. This also results in a simpler and more easily maintained code-base.

Hiring – A great training program for development is an excellent selling point when looking to attract new development talent. Top tier developers want to surround themselves with others who are as good or better than themselves. A great training program is a good way to develop that talent and is something top talent looks for.

Preparation – Developers with training in upcoming technologies are quicker to see how they can implement them in their organization to the good of the company. These developers are better able to see industry and social trends which can give your company an ongoing competitive advantage. Also, they will be able to point to reasons why a new technology choice may not be right for the company. When the company’s bottom line is healthier, everyone wins.

Teamwork – Developers who train together work well together. They tend to develop camaraderie and work more effectively at solving problems as a team. Training together also helps expose developers to each other’s strengths.

Job Satisfaction – Well trained developers are are learning developers and let’s face it… if we didn’t like learning we wouldn’t be in this profession. When developers begin to feel stagnant they may start looking for work where they can grow or they may also become careless and write poorly thought-out code.   A good training program will help to keep developers satisfied and satisfied developers don’t go out of their way to look for other employment. This allows the company to retain their existing workforce longer and save the money and overhead involved in hiring (training, recruiting fees, bonuses).

——-

Potential Technology Training Topics

Topics should be chosen based on their applicability to the needs of the business. No responsible developer would expect otherwise. Also, real business problems should be given to help teach theoretical concepts through workshops (more on this below).

Methods of Training

Technology training can be very expensive if allowed to be. Hiring outside training companies, attending seminars, and certifications should be supplemented with sessions presented by internal experts, videos freely available online, and book discussions.

Valuable employees should be encouraged to train on their own time in addition to being given training on company time. This give and take approach will help your company realize the best gains by encouraging a knowledgeable and proactive culture among developers.

Online Videos
1-2 Hours – Daily/Weekly/Monthly
Free
These can be held during lunch or outside normal work hours. If a developer misses the presentation they can catch up on their own. A great resource for Microsoft related videos is http://channel9.msdn.com/

Developer Presentations
1-2 Hours – Weekly/Monthly
Free
Could be held any time. Presenters should be by volunteer only. Topics should be in line with the current curriculum.

Workshops
2-4 Hours – Monthly
Free
A workshop should follow a series of videos and/or developer presentations that cover the same or similar topics. No specific homework but the implementation should be something of value to the company at least as a prototype. Sessions held during business.

Workshop Follow-up
30 Minutes – Monthly
Free
Developers present their solutions to the workshop problems. Should take place a few days after the initial workshop.

Book Discussions/Club
1 Hour – Weekly
Cost of Books (Free-$80 per participant)
Developers vote on and read a technical book each month and discuss it for an hour during lunch or work hours. Books could be purchased by the company or by the developers. There is a lot of great free material for discussions available online as well.

Onsite Training Seminars
1-N Days – As Needed
Varies: $1000-5000 for up to 25 attendees
An inexpensive, onsite training. The internet is your friend… do a little research and you can find many companies offering this type of service.

On-Demand Video Training
1 Year – Annually
$100-500 per user
This type of training can be handy because is is available at any time and the people who produce/present are professionals who are not only experts in the field but can also give great presentations. There are several providers of this kind of content including Tekpub, PluralSight, and Peepcode. **
http://pluralsite.com/
http://tekpub.com/
https://peepcode.com/ 

**Tekpub and Peepcode have been purchased by Pluralsight since this was written. Looks like we’re going with Pluralsight!

Safari Books Online
1 Year – Annually
$199 or $460 per user
Safari Books offers hundreds of titles on technical subjects related to the development profession and Microsoft specific technologies.
http://www.safaribooksonline.com

Offsite Development Conferences
2-5 Days – Annually
$500-5000 per attendee
These are the conferences that really get the creative juices flowing in developers. Most major tech companies have at least one developer conference per year (Google, Apple, Facebook, Microsoft). Most companies with a decent training budget send their developers to one per year (almost never 2+). Estimated cost includes hotel and transportation.

developer training
Offsite Developer Training

Certifications
Varies – Varies
Varies
Some companies pay for developers to train for and take development certification tests.

Graduate Degrees/Tuition Reimbursement
Varies – Varies
Varies
Many companies offer to reimburse employees engaged in higher learning. This is another great opportunity. Encourage your employees/coworkers to take advantage of this benefit if it already exists!

——-

As you can see, the options for training developers run the full gamut of price, time, and commitment. The great news is, even if your company has little or no budget for training, all you need is a couple committed developers to get started with the less expensive (free) types of training. Now is the time to start training so that your company will attract, retain, and benefit from more highly trained and competent developers!