My Personal Software Development Approach

I've worked in IT for over a decade now and I thought I might blog a bit about how I like to approach software development. I work with a great team of developers at my current employer and I'm reletively happy here; therefore, any comments I may make that sound remotely negative, are in response to the negetive feedback I've gotten on the 'My Collection' application.

By negetive feedback, I don't mean, 'Hey can you make it do this' or 'I think it stinks'. I'm referring to feedback like 'YOU CAN'T CODE FOR CRAP!!!!' or comments that make not-so-oblique references to intelligence, sexuality, political beliefs, religions beliefs, etc....

Here is goes:

No Excuses - Let nothing stop you!

I flunked out of a programming class in high-school and I never let that stop me. Over a decade ago, I had a manger tell me I wasn't going to be a good programmer and I didn't let that stop me. Different people develop differently in their careers. Pick your goal, and don't give yourself any slack in getting there. Set your goal and get to it. If you fail to hit your target, it's YOUR fault not your managers, companies, bosses, or ex-spouses fault. Get it done!

Keep your self-evaluations at the front

I have never liked hearing from my manager how good I am at my job. I know my shortcomings and usually take steps to correct them. What I like to hear from managers is constructive feedback like, "How would you feel about this approach next time..." or "The company has a need for this skill, you might want to check it out"

Don't marry any specific technology

I've been on a few interviews where they have asked me a question like, "Are you a [.NetPHPJavaCC++] programmer?" My answer is always, I use whatever best fits the needs. That doesn't mean I always pick C if I need speed. I have to consider the established infrastructure and company talent pool; however, personally, I try to study frameworks and paradigms and not a specific language. That doesn't mean that while working in a platform or language, you should not take an effort to learn it's idiosyncrasy's. But I've meet a LOT of out-of-work Cobol programmers and they were trying to get up to speed in C# of Java, or some other language.

Don't be afraid to ask for help

I've worked with developers that would spend two days trying to figure out a problem that they could have solved by either a 5 minute Google search or talking to a colleague.

Don't be afraid to admit you were wrong or made a mistake

I'll admit some bosses/companies make this hard but even the BEST golfer rarely hits a hole-in-one.

Don't be afraid to admit you don't know

There is nothing worse than someone who will simply not admit they don't know and worse, make it up. They print tech-manuals because everyone cannot remember everything...

Don't be EVER LIE!!!

This is in reference to the first three really. In software, honestly is always the best policy. If you boss asks you to lie to a customer, quit. It will only get worse from there and they are more than likely lying to you! Instead, try to say things like, "We don't publicize our bugs", or "We had a bug in our code"

Micro changes over time not Macro changes rarely

I've gotten some feedback that I change 'My Collection' to much. I think they are correct, but I also do that intentionally. I am not trying to release every item on my TODO at once and I prefer to roll them out over time. That way, I can isolate the issue if there is a problem and also I just don't have the resources for monolithic releases.

Document now, pay NEVER

Documentation is the key to software maintainability. It should be a law really but since it's not, it should become a compulsive habit at least!

Take constructive an un-constructive criticism with a smile

As much as I hate oblique references to my sexuality, intelligence, etc... It never every pays to shoot back. Most people want to help. I've gotten very little negative feedback and most of the issue people bring to my attention are noteworthy and implemented. Also, make sure you tell someone no rather than ignoring them.