I was reflecting on some of the things I’ve experienced while in the software engineering field. There are some big mistakes I’ve witnessed and made. I’m going to share what they were and I hope you gain insights of how to approach some situations… especially if you are new to the industry.

Clever code

During my first job, I was helping to write a generic report builder application. We needed a method to parse a Date out of an oddly formatted string. Being fresh out of college, I was excited to show that I could write something that would parse immensely fast — and I did. There was one major problem, no one else understood it. When it came time to refactor, a senior engineer said this to me and I’ll never forget it:

Programming languages are designed to be understood by humans.

If your code is good enough to stick around it will have to be maintained and probably by someone else. There are exceptional cases of course, but remember that compilers often make the same optimizations (or better) than the ones you cleverly devised. Learn from my mistake, don’t be clever.

Neglect your users

You are neglecting to involve your users if you: only gather and change requirements before coding, show no prototypes (or even storyboards) to your clients, or only have a few people “see what they think”. Requirements tend to change as soon as a user uses. Plan for this and make something that your user actually needs instead of what they thought they needed.

In this instance, it was my company at fault here. We often got new tasks because the user wanted something different than what we gave them. I desperately wanted to call a customer directly and ask what they wanted. In fact, this is one of the reasons (of many) that I left and moved on to Sun. Your career and project depend on your users. If red tape prevents you from involving them, leave.

Stick to what you know

So often, a programmer may know of a technology that will that exists that fits the problem domain, but often they are unwilling to make the leap and just learn it. This doesn’t always have to be another language, but sometimes different frameworks or even just classes that hasn’t been used before.

Programmers that don’t really know what they’re doing will simply copy someone else’s code through trial and error until it “works”. Reading someone else’s code is a good way to learn, but there must be effort put in to understand it. Only when it is understood should it be copied, then of course you really ought to stay DRY. Take that time to make yourself a polyglot. Soon enough, your career will depend on it.

Conclusion

Choose to be better. You have a good start reading blogs, but I encourage you to apply all that you can for the benefit of learning.

These are just a few things I’ve seen so far. I’m sure you can come up with more examples of your own. Please share.