Should Bad Code Be Illegal?

A junior developer on my team asked me a rather interesting question recently.

If you were able to make laws, would you make bad code illegal?

I have a reputation where I work as being rather hard-nosed about not allowing hard to understand and maintain code into the codebase, so my answer surprised him.

No, I would not make bad code illegal, and there are very good reasons for having this opinion.

First, everyone writes bad code before they write good code. Whether it’s your first time coding in general or just your first time coding in a new language, with a new framework, etc, you are going to write bad code. I’m sorry. It’s just a fact of life.

Nobody starts out writing amazing code. Not me, not you, not Uncle Bob (in fact, Uncle Bob is open about the fact that he was a horrible developer when he started, just like the rest of us). We all get better by writing bad code, learning from our mistakes and pain, and, if we’re lucky, mentors helping us to see where things can be improved.

Second, “bad code” is rather subjective. What standard are we using for what “bad” code is?

Is it code that costs the business unreasonable amounts of money due to being full of bugs and difficult to maintain? That’s not a completely terrible definition because we can tie it to some external benchmark, but it’s still probably a bad idea since there is a risk/reward factor of why decisions were made at the time that may not be known at some later date.

Is it code that Developer X (whether me, Uncle Bob, or Joe in the cubicle across the hall) would look at and give a laundry list of things that need to change? For any given code, you can find some developer that would find flaws in it – whether it is inefficient, or it doesn’t implement their favorite pattern, or any number of other complaints.

Is it code that, six months from now, you will look back at and wonder what the heck you were thinking when you did it that way because there are so many better ways to accomplish what this code does? Here’s a hint. This should be most of your code. You didn’t know as much 6 months ago as you do now.

Third, sometimes bad code is necessary.

Yes, you heard me. There are times that it makes sense to write bad code.

If you are writing a script to perform some one-off function that you are seriously never going to use again, pretty doesn’t always matter that much. If writing code for 5 minutes and then throwing it away can save you hours of work, go for it. I’ve done it before, and I can almost guarantee that I will do it again.

Sometimes you need to fix a catastrophic flaw in a mission critical piece of software, because the company is losing millions of dollars per minute while the flaw exists. In that case, you have to do whatever you can in order to fix the issue, release the patch, and *then* go back and make it maintainable.

The same is true if we are in a startup where the money is limited, time is fairly short (as it is generally a function of money in this case), and we need to get a Minimum Viable Product out in front of users so we can start making money. This is another case were “Make it work, then make it better” can be the correct (and sometimes only) course of action.

We may not like it, but sometimes getting it to work right now is the right choice. These situations fall under the heading of consciously taking on technical debt with every intention of paying it back later and this is a very important business decision. If it’s a matter of “We can release it now and be able to make payroll” vs “It will take another month to make it perfect and we’ll be unemployed by then”, well, the choice is fairly clear then isn’t it?

Thankfully, most of the code we write doesn’t tend to fall into those categories, so we can make the effort now in order to make the code clean and maintainable, but we can’t ignore that those possibilities exist.

Making a law that is, on the whole, completely subjective and capricious is a just plain bad idea. As a general rule, when we write code that isn’t amazing, at worst we lose time in figuring out what is going on and/or fixing some bugs. Nobody generally dies from bad code (there are cases this is not true, but they are not the norm), and we can always make a conscious effort to improve it once the crisis is averted.

On the whole, yes, we need to strive to write clean, maintainable, bug free code, but we can’t be completely inflexible. If you want to make it a crime to write bad code, make the punishment be to learn how to write better code. I think that’s a fair sentence.

 

Current mood: Calm

Current music: Midnight Oil – Beds Are Burning

Encouraging the Next Generation

Recently, some of the people where I work have started a weekly writing prompt in order to get people to blog more often. This week's topic is “How do we involve the next generation of young minds?” and was inspired by two of my co-workers building quadcopters with a group of students in the northern part of the state.

This is a very open topic and very difficult to cover in a way that is less wordy than a copy or War and Peace (or at least your average work by Stephen King). However, I think it can be approached by breaking it down into a number of subjects which need to be addressed.

That being said, let's begin.

Start Them Early

The truth is that the earlier you start to instill curiosity and creativity in people, the easier it is to get them to continue on that path. There are a number of ways to do this, but if you're looking for ways to get a small child started, Legos, Lincoln Logs, Tinker Toys, etc are really a wonderful way to get the ball rolling. They offer nearly endless ways to combine pieces creatively, are tactile (which helps a lot of people, children or not. Never underestimate the value of physically building and handling something), and are generally fairly affordable.

Realize that not everything has to involve circuitry and code. Even things like basic woodworking projects can help instill creativity and the engineering mindset. I've built everything from birdhouses and toolboxes to actual buildings while I was growing up and I learned something valuable from every project.

As they get a little older, introduce them to things like crystal radio kits, 130-in-1 experiments kits (yes, they still make those), snap circuits and even simple programming languages like Scratch and Logo. A little later still get them involved in writing code on something like a RaspberryPi (it's fairly inexpensive and if you somehow manage to botch the os, just re-flash the SD card and start over. You can even extend it in order to interact with hardware). Tangoes are also a wonderful, inexpensive tool for teaching spatially related problem solving.

You want things that are simple to get a beginner's grasp of yet versatile enough to keep their attention after they master the basics and, most importantly, make them want to learn even more.

Mindset

“A mind all logic is like a knife all blade. It makes the hand bleed that uses it.”

- Rabindranath Tagore

Logic is a very important part of being successful in technology fields. However, there is another part of the equation that is often overlooked – creativity. You really do need both the ability to think your way through a problem as well as the ability to look at a problem from a completely different angle than other people at times.

We need to foster not only logical thought, but also appreciation of and involvement in the arts. I would almost argue that the type of art doesn't matter nearly as much as being involved. Painting, drawing, writing, music, theater, and countless others – all of these things exercise your brain in ways that simple logic based problem solving doesn't.

On the logical side, we need to encourage the next generation of technical people to cultivate the skills to look at situations objectively, come up with a set of possible answers, and then evaluate or work through them (revising their general assumptions as they uncover more information) until they reach a conclusion. This is the time for measured experimentation instead of just wildly poking at a problem until something happens (though, admittedly, sometimes poking at the problem is necessary in order to uncover behavior).

Encourage the next generation to ask questions. That's not to say that you should spoon feed them the answers since guiding them through the discovery process is both an extremely effective way of teaching and often fun for everyone involved. However you do it, you should encourage them to ask the “whys” and “what ifs”.

Continuing in the vein of asking questions, foster the questioning of authority. If someone says “You can't do that” they should ask WHY. If it's because doing that thing is dangerous, that's one thing. If it's just because they don't think it can be done or because of other foolish reasons (“getting above your station”, “that's not something that proper girls/boys do”, etc), they should be encouraged to CHALLENGE IT.

We are, among other things, professional troublemakers. We create and change current reality as a part of our jobs. It's what we do. Innovation is inherently disruptive. Embrace that; don't try to stomp it out of the next generation.

Encourage reading. I can't stress this enough. Fiction, non fiction, philosophy – just read. It exposes you to different voices and approaches from your own. It's literally a different view on the world, and being exposed to that will help you grow.

Quick Feedback, Small Victories

Make initial victories easy to attain. This is especially true for younger children. Defeat is frequently demoralizing. Starting off with a victory encourages people to continue. It doesn't matter if it's just making a ball bounce on the screen. Give them something that provides near instant feedback that they have done something with a real, visible result.

As they progress, keep feedback loops tight even though the difficulty of what they are doing increases with time. Yes, I realize that this sounds a lot like Agile practices.

Make it Safe to Fail

“I have not failed. I've just found 10,000 ways that won't work.”

- Thomas A. Edison

Failure, both professionally and personally, is an occasional fact of life. No matter what we try or how hard we work, there are times when things just won't happen the way we want them to.

The problem is that we have stigmatized failure to such a degree in this society that some people are afraid to even try because they might fail. This needs to stop.

Teach people that it's okay to fail on occasion. That's not to say that we should excuse laziness, but re-enforce the idea that failure occasionally happens, treat it as a learning experience, and teach others not to fear making a mistake.

Access to Tools

It may not occur to a lot of us in this field that not everyone is as well off as we are from an economic standpoint. Not everyone has ready access to the equipment needed to learn various technical skills. This is especially true in both poorer urban and rural areas.

Access to programing tools (IDEs, etc) has become considerably cheaper thanks to open source tools and educational/community licenses offered by companies like JetBrains and Microsoft. However, for some people, computers are still an expense that they can't justify (even if they are much cheaper than when I started learning to program).

That's not to mention the expense of things like quadcopter kits. Some of the things that you need access to for some projects are simply out of reach for a number of individuals as well as some school districts without outside help.

Access to Mentors

When I started out, I didn't have any mentors to help me learn how to code. The internet wasn't an option (yes, dinosaurs roamed the Earth and we had to walk to school uphill both ways). I had never even met or spoken to a professional software developer until I was in college. In fact, the only other people I knew who wrote code were a few friends in basically the same situation as myself.

It would have been much easier and a lot less discouraging if I had had access to mentors (even online) instead of having my only resources when I started out be the manual for a TRS-80 color computer and the occasional code sample in magazines borrowed from our very small public library (I told you that dinosaurs roamed the Earth at the time).

If you want to encourage the growth of a new generation of creative and technical people, you have to literally be there to encourage and guide them. Answer questions on the internet, make yourself available to schools/after school clubs and programs, and generally be a good community member.

Parental Involvement

This is the really difficult one. In order to encourage young people to go into technology based careers, their parents have to be positively involved. They can't just treat the computer as a way to babysit their child or, possibly even worse, view everything that their child does, no matter what it is, as simply “playing on the computer” like my parents did (which, I might add, included programming homework in college).

Keeping up momentum when it feels like nobody cares or you are being actively discouraged is extremely difficult. Not everyone is as hard headed as I am.

Parents don't even have to be experts in the field. They just have to be positive influences. Be curious about what your child is doing, encourage them, have them show off what they're doing to you a bit. Be a cheerleader. It's important.

Show Me The Money

Show people that there is a (generally) fun, well paying job doing work in this field and that it doesn't matter if they're a girl or a boy or even what socio-economic background they come from as long as they work at it. After all, it's important to be able to do things like pay your bills, go on vacation, and buy sandwiches.

As I said, this is by no means an easy problem, and this is only the short list of things that can be done to help, but it's a start and even if you can only manage a few of them that's better than the alternative.

Current mood: calm

Current music: Murray Head – One Night in Bangkok

Your Code Sucks

 

I’ve seen a few people that I know berate people for the quality of their code and say things like they should just go and deliver pizzas.

You aren’t your code. Code is an expression of the skill, mindset, and situation facing the person who wrote it at the moment it’s made. Nothing more. In fact, it may be the chaining together of those factors from several people as the code is maintained.

There may be things about the situation that you don’t know. Maybe the person was under insane time constraints. Maybe they were thrown into a technology they had no experience with. Hell, maybe they were just having a bad day.

You may not like maintaining the code – I know I don’t, but I try not to berate the person doing it because I don’t know what lead there. (If I know the person in question and know that they just don’t care, that’s a different story)

There are a couple of appropriate responses to “your code sucks”.

• Where can I improve?
• Yes, it sucks. So does everyone else’s. I’m working to improve. Are you?

Improvement is the important part.

Yes, my code sucks. It always will, but it gets better every day.

Does yours?

 

Current mood – tired

Current music – 10,000 Maniacs – Candy Everybody Wants

I'm Not an Expert

 

I’m not an expert. On anything, really.

Don’t get me wrong. There are things that I’m good at, but I wouldn’t call myself an expert on them.

Part of the reason that I don’t consider myself an expert on anything is that I’ve done so many varied things. I’ve never settled into just one area of development (or anything else).

I’ve had a lot of hobbies, interests and jobs that range from martial arts, to carpentry, blacksmithing, gardening, cooking, and (obviously) software development (among many other things).

That kind of spread isn’t exactly the sort of thing that screams “I’m the greatest person in the world at one thing.” It does, however, lead to being able to look at problems from a lot of different angles and helps you come up with a solution to something you may have never seen before.

I sometimes get asked what my specialty is by people who won’t take “I don’t know” for an answer, and the only thing I can think to say is that I’ve learned to ask questions that get me the answers that I need.

I may not know a thing, but I can generally figure out a way to find the answer.

I suppose that you could say people like me specialize in being generalists, but I think we just suffer from a combination of ADD and having to take on multiple roles. Somehow, it works out, though.

Current mood: thoughtful

Current music: Goo Goo Dolls – Give a Little Bit

Motivation

It’s generally really easy for me to keep going if I’ve already got a bit of momentum, but if things have derailed me and caused me to focus elsewhere, Newton’s First Law decides that it also applies to motivation and proceeds to kick my backside.

Translation – if I stop, it takes real work to get going again.

It’s also fair to say that, for me at least, large tasks are intimidating, but breaking them into smaller chunks makes them more manageable because it lets me just consider the current step and leave subsequent steps for a little later.

Big = difficult. Little = easier. Makes sense, right? Less stuff, less to be overwhelmed by.

Or, to paraphrase my sifu a bit “Concentrate on now right now. Later will come when it is time.”

A few years ago, I found a way to motivate myself when learning something new from a book or video as well as when working on projects. Thankfully it plays into the fact that I’m a big fan of marker boards (I have several in my office to help keep myself organized and to brainstorm) so it doesn’t take any additional expense on my part.

I write the name of the book or video series on the marker board and then put down the chapter or video numbers. As I work through it, I erase the numbers for the chapters that I’ve covered.

 

This does two things:

First, it lets me keep track of where I am. This is especially helpful if I’m doing a video series or a web-based lesson plan.

Second, it lets me see that I have actually been making progress so I don’t get lost in the feeling that I’m never going to get anywhere in what I’m doing (I’m pretty sure that I’m not the only one that has this problem. It’s downright overwhelming to look at how much you have to learn, and every time you learn something, it shows you other things that you need to learn).

Some people will prefer to strike through the numbers or put a check mark next to them after they’ve finished, but I prefer to erase for one very simple reason – it lets me actually SEE the list of things I need to do shrink. If the numbers are still there, the size of the task never visually changes so my brain still says “Hey, there’s still this daunting list of things that we have to do.”

If I erase the numbers, my brain goes “Wow. We’re making progress! Maybe we can do this thing after all.”

Yes, it’s a stupid psychological trick, but in my case it works.

I guess that means it’s not so stupid after all…

 

Current mood: undecided

Current music: Adam and the Ants – Room at the Top

Recruiters

The tech job market in Columbus seems to be picking up quite a bit. This is a wonderful thing for a lot of people since we like to be able to pay rent and buy sandwiches.

Unfortunately, it also means an increase in the number of people that call themselves recruiters whose only purpose is to spam as many people as possible in the hope that some company will hire one of them so said “recruiter” can get a commission.

These people are not really recruiters. They’re parasites. Real recruiters are a completely different creature.

If you’re a “recruiter” and are located in an off shored call center, you aren’t really a recruiter. I’ve gotten a few calls of this sort in the last few weeks and they’re driving me up the wall – Broken English, lots of call center noise in the background, and follow up emails that say things like “I enjoyed speaking with you” when all they did was leave a voicemail.

If your “job description” is a page full of bullet points that tell me absolutely NOTHING about the position, you’re doing it wrong. I once got an email from a “recruiter” that had about 20 bullet points worth of “description” and all it really said was “write code, conform to company standards, and you won’t be supervising anyone”.

Don’t tell me that you have something you think I would be “perfect” for without telling me why. This is especially true when the job is for something I’ve never done before. This is the most common kind of resume spammer “recruiter”. Thankfully they also tend to be the least tenacious and easiest to ignore.

If you’re contacting me about a job in Ohio, but you’re located in New York, you’re doing it wrong. You can’t know about the developer community in Columbus, Ohio if you’re located in Rochester, New York. If you’re not in the geographic area that you’re hiring for, you’re probably doing it wrong (there are exceptions, but they’re not that common).

Bad recruiters leer at and hit on my girlfriend while she’s at an after users group meet-up with me (true story, sadly. Karyl almost dumped her drink on the guy).

By contrast, good recruiters generally display the following qualities:

• They work through word of mouth networks in the developer community. Referrals are the source of most of their candidates.
• They will tell you the name of the company that they are trying to put you in touch with to make sure you haven’t already submitted to them since multiple submissions basically kill your chances.
• They take some time to learn what you’re looking for instead of trying to shoehorn you into every position that comes across their desk.
• They take time to help prepare you for the interview. They will give you an idea of what to expect both in terms of interview techniques (if there are any tests, etc) and corporate culture including suggestions of how formal or casual to be in the interview.
• They do not act like a creep and hit on my girlfriend.

Good recruiters are worth their weight in gold. Bad ones only serve to make everyone’s lives difficult. Sadly, the good ones are also about as rare as gold while the bad ones abound.

Current mood: tired

Current music: The Call – Let The Day Begin

Equal Rights

Tonight, something that I believe strongly in came out in conversation. It started with Jim Holmes tweeting regarding an article written about another developer that I follow and have chatted with in the past:

“Disagree with Women-Only anything in IT. Why put up more walls? #fail RT @RWW Women-Only Programming Classes http://rww.to/aU9kme”

I happen to agree strongly with this, and said so. One of the devs that follows me, however, was of a different opinion and tried to justify the opinion, only to be shot down not only by Jim, but by me and even by my girlfriend, Karyl.

He went through a number of arguments, trying very hard to find something, anything, that would validate his claim and basically ignored anything that was used to counter him. Some of them, and my more lengthy responses (which, naturally, would not fit on twitter) are here.

“In this instance, I can understand it. The men are the main deterrent to potential female programmers. Plus, then they can focus on the material rather than deflecting awkward advances the whole time.”

I disagree. The deterrent to potential female programmers are the potential female programmers themselves. Women are not the only people that get hit on in college or while trying to learn or work. The number of classes that I was in where female classmates were trying to get me to go out on dates with them was rather high and I still managed to do all of my work. Besides which, most of the women in my CS classes (with a few exceptions) were under the impression that anyone who spoke to them was trying to hit on them and that really wasn’t the case.

From my personal experience, the women in the other engineering disciplines tended to be more driven than the ones in CS and were a lot more fun. There were more girls that dropped out of the CS program because it wasn’t “fun” or it was “hard” than because people were hitting on them (In fact, I can’t think of any of the girls I knew in those classes that stopped doing it for that reason).

“So, you're saying you don't think women should be allowed to have male-free anything?”

Are men allowed to have men only anything? No? Then there’s your answer. I believe in Equal rights. We are not getting into this “some people are more equal than others” mindset. That is a crutch and causes people to strive less if you constantly tell them “Oh, that’s okay. You’re a [x], we’ll lower the bar for you.”

Screw that. I want a professional in *any* profession to be held to the same standards as any other professional in that profession regardless of gender, skin color, or any of the rest of it.

To which I got the response of asking me how many men I’ve known who have been raped.

Bad question. And this made me very glad he wasn’t in the same room with me. I have good impulse control, but rape is not a woman only issue and it is not something I take lightly (nor is abuse in general).

For the record, I’ve known two that I can think of. Men who are raped undergo the added stigma of nobody believing them because, of course, rape can’t happen to men. Ask Karyl about her friend who was raped and was accused of being the one who did it instead. It has literally ruined his life.

Add to this the fact that many domestic abuse shelters will not accept men (who can be, and more often than you would believe, are victims of domestic abuse) and you start to see why this is a hot button topic for me.

Rape is not funny. Rape is not something that should be used as an argument against equal rights. Rape is also not just something that happens to women. I’ve known women who have been molested and raped as well and I don’t find it funny from either end. In fact, the woman that I loved more than anything else in this world was raped so I think I have some insight into how absolutely fucking horrible it can be (no pun intended and strong language more than justified).

“I've never been in a situation where I felt uncomfortable because the group was dominated by women.”

I have. It was not really fun. I’ll tell you something else – that group of women was more openly sexist and offensive than I’ve ever seen a group of guys be around a woman.

I’m not excusing guys who try to coerce women into doing things against their will. That sort of thing is, in my opinion, inexcusable, but it is not limited to guys. It’s not excusable from anyone, male or female (and, trust me, it happens with both).

Jim, the other voice of sanity, stepped in stating that he didn’t buy the attitude that all male programmers did was make passes at female programmers (and I agree).

This prompted a rather predictable response by our new “friend”:

“I'm not saying we do. All I'm saying is that if that FEAR is keeping one woman out, and the fem-only class lets her in, its a win”

No. What is keeping that person out is their own fear, not reality. If you are uncomfortable learning around men, how will you feel when you get out into the real world and work on development teams which, nine times out of ten, contain men as well as potentially other women?

“I theorize that by becoming exceptional in their trade, the unease when dealing with men is lessened due to being capable devs”

You become exceptional through practice and work. That involves working with and around other people, including men. You do the work and learn from it. You also learn from the people around you. That’s how you get better at anything (not just software development).

“By that logic, a group of women is not capable of creating great programs?”

No, by that logic, people who are afraid and never strive are not capable of creating great things. Letting yourself be afraid of your very surroundings and letting that fear control you means that you will never do great things and, in fact, may not do anything at all.

Greatness is accomplished by carrying on in spite of your fears (or sometimes even because of them). Giving up and going home because they let the boogey men in their head control them never really got anyone anything.

Am I afraid sometimes? You better believe it. However, I do my best to work through it. Sometimes it works. Sometimes it doesn’t. But I’ll tell you that it’s better than letting what *might* happen rule my life.

You’ve got to try for yourself. Nobody else is going to do it for you, and even if they did, it wouldn’t mean nearly as much to you as it would if it was your own striving that got you there. Others can, and hopefully will, help you along your way, but you have to keep striving and push yourself to find your true boundaries. Then you have to work to break those boundaries.

I went on to explain why I have some of the views that I do – the fact that I’ve known women who were great and men who sucked (and the other way around), that I’ve taught and trained with martial artists of both sexes with various skills and skill levels, that I’ve known victims of domestic violence (both male and female) and that I don’t subscribe to the mindset of “men are evil and scary and need to go away” because that cheapens everyone’s accomplishments.

“My experience is that I'm an arrogant asshole, and I understand why a woman (or man) wouldn't want to be in a class with me.”

Finally something we can agree on. However, that’s a problem with you and not a problem with all men. All men aren’t like you (and for that I’m thankful).

In all honesty, folks, I don’t care if you’re a man or a woman. I don’t even care if you’re green and furry. I believe in equal rights, but that means equal responsibilities as well. If you want to bridge the [gender, racial, whatever] gap, stop using that thing as a crutch and strive. *That’s* the way to give people positive role models. Role models are created out of overcoming adversity.

You can’t create positive role models out of people that you let have an easier time than everyone else. Greatness is taken and achieved, not given and people need to realize that. It requires striving, not going easy on someone because they’re somehow different (whether real or only perceived). That only perpetuates the “I can’t do it because…” mentality.

"Freedom is something that you need to actively acquire. It’s not something that’s given with no strings attached. To be free means to take responsibility, and to prepare yourself for what’s to come."
- Charles Beams, "Eureka Seven"

The same is true of equality. In fact, equality and freedom are often very close to one another.

Don't beg for things. Do it yourself or else you won't get anything.

Current mood: grumpy
Current music: Eve 6 – Inside Out

What I Can Offer and What I’m Looking For

As I’ve said, I’m currently in the market for a jr-mid level .NET developer position in the Columbus, Ohio area. I really dislike being a one person shop. It always feels like I spend more time hunting for new projects than I spend doing them, and that’s just not my idea of an ideal situation.

That doesn’t really say much, though, so I thought I’d put down my wants in writing in order to not only get them out for others to see, but to get them straight in my own head.

First, however, I’ll briefly list some of the things I have to offer (this is by no means an exhaustive list).

What I bring to the table

• I have several years of experience in writing code.
• I excel at solving problems and enjoy doing so.
• I can explain technical issues to non-technical people.
• I have a professional, yet relaxed attitude.
  
• I write well.
• I am adept at gathering requirements.
• I tend to be a calming influence on the people around me.
• I learn new skills quickly.
• I love writing software that makes a difference to the people who use it.

What I want in an employer (the bullet point edition)

• A place where I can learn and grow.
• A sane work/life balance.
• A sane salary.
• The ability to, preferably, work around good people who really know their stuff.
• A relatively relaxed environment is a plus

Now, bullet points are great (or horrible, depending on who you ask), but we can get into a little more detail on my wants/needs.

A place where I can learn and grow –
I honestly want a place where I can expand and hone my skills as well as get back to using some skills that I feel have atrophied since I’ve been on my own, such as leadership and presentation skills.

One of the downsides to being independent is that you have a harder time setting aside time for professional development because you always feel like your time should be spent either doing work or finding more work. You also frequently have a really difficult time getting new perspectives on problem domains.

Sane work/life balance –
I don’t expect every day to be 9 to 5 because, let’s face it, that basically never happens. There are always the occasional crunch times at the end of projects or at the end of a cycle in the project, and that’s fine. The problem is when you are expected to work extended hours on a regular basis as a matter of course.

What I do want is for the occasional crunch times to be just that – occasional. I understand that I’ll find myself staying late or getting in early if there’s an emergency, to prep for a big presentation, a sprint at the end of a project, etc and that’s fine. What I don’t want is to be expected to work for 70+ hours a week.

I love writing software (and solving problems in general). I consider it fun, but there are other things in life that need to be taken care of as well.

Sane salary –
Basically, I want a salary I can live on decently. What I’d like to be paid depends on the position. I realize that lower level positions pay less than higher level positions, and sometimes you have to take a step backward in order to move forward.

If you’re concerned that I’m pricing myself out of a position, talk to me. We may be able to come to an agreement. I honestly want to make the jump, and some things are negotiable in order to make that happen. Besides, there’s been a fair amount of variation in the salary ranges of a lot of the companies I’ve talked to (though they tend to cluster in a reasonably narrow range, so I consider that a decent indication of what I can probably expect).

The ability to work around people who really know their stuff –
This sort of ties in with and extends learning and growing, but I thought it warranted its own point.

I find inspiration from working around other people. It may sound cheesy, but it’s true. Sometimes, just being around other people is enough to make me find novel solutions to problems. Additionally, I tend to learn a lot just from observing and listening to the people and things around me and am motivated by being around people that are better at things than I currently am.

This isn’t limited to just being around experts, though. I’m a firm believer that you can learn something from everyone, so being around other people in my field (and other fields) is a plus regardless of relative skill levels.

Relatively relaxed environment –
By relaxed, I don’t mean Hawaiian shirts and Nerf gun fights. Clothing wise, you’ll usually see me in khakis and a polo or button up shirt.

Relaxed, in this case, is more along the lines of non-hostile. I’ve seen a few companies where the people in charge seem to feel the need to berate and dehumanize the people that report to them (directly or indirectly).

In my personal opinion, that’s not a way to keep good people or to keep them motivated. The world may not be sunshine and roses every day, but you shouldn’t spend every day wondering when the (hopefully) figurative chair is going to fly at your head.

We tend to work better when we aren’t stressed unnecessarily, and since I want to work to the best of my abilities, it seems logical that I don’t want to be in a hostile environment.

Naturally, a discussion of this sort could go on for a considerable amount of time, but I think that covers most of the major points of what I have and what I want. If I sound like a person that would fit in with your organization or you know an organization that you think I would be a good fit for, please feel free to contact me.

Current mood: decent
Current music: Tom Petty - I Won't Back Down