Charles Rowe dot com

Coding Horror posted an article about User interface that was based on a interface usability post by Tantek Çelik.
Between the two posts, the clouds parted and I was struck square in the face with an epiphany. The way I view interfaces has changed for the better. I have come up with 5 of my own items to extend Tantek’s line of thought.
(more…)

Today, I am privileged to interview JT Koffenberger of Delmarva Group and CIO Podcast.
JT is a consulting CIO for my company who is tasked with redesigning IT to more efficiently meet the needs of a rapidly growing business. JT is currently restructuring the IT department to fulfill a larger role in software development as the business responds to growing customer demand.
Because of JT’s significant experience on both sides of the development “fence”, he has valuable knowledge to share with developers who are looking to understand the management point of view.
JT has agreed to answer some questions regarding software development as a career, what it takes to gain the attention of prospective employers, and offer up some insight from someone who has “been there”.

(more…)

The Codist has an article today entitled, “So You Want To Become A Programmer“.
The post has 6 solid entries for getting a person imbued in the programming culture, and landing the first job. If these sort of tips interest you, I strongly suggest you give it a read. I humbly offer my own additions to the list:

7) Code cleanly
This could be an amendment to #4 . Writing clean code can give you a distinct edge if you are lacking experience.
There are so many people that write spaghetti code with the one letter variables, and 100+ line functions who brute force their way into the profession through sheer problem solving ability and force of will. When you apply for an entry level position, you are often applying for the ability to mentor with a senior developer, or a team of developers. They would rather have a “clean slate” with no bad habits, than a hot shot problem solver who writes in their own dialect.

8) Learn development methodologies
This one is two fold:

1. Even if you are a solo developer, you are never coding alone. Part of being a professional programmer is insuring that when you get hit by a bus, the application doesn’t go with you. You need to learn what is expected of a good application, and what your future project leads or maintainers would like to see.
2. Learning development methodologies is also a good idea because it will give you a better idea how to interact with a team of developers. Lone coders are a dime a dozen. If you know how to play nicely in the sandbox, you will be more attractive to potential employers. A team can’t rearrange itself to fit your quirks. Showing that you understand when and how to communicate, and an idea of the many phases of development will lower any risk associated with your employment.

9) Learn to love over-time.
If you program, you are going to be lucky to have a 40 hour week. Yet, You are probably going to be paid for 40 hours of work as a salaried employee. You need to come to grips with that fact. Few people -enjoy- working and not getting paid for it, but is going to happen. On top of that, you have selected one of the most fluctuating fields out there. It is on your time, and your dime to keep pace with emerging technologies. This is one aspect that separates a good programmer from a great programmer.

10) Get the job done
The previous points have been about doing your job well. This point is about WHEN you do your job.
All businesses and project owners operate under deadline. If you accept a project with a deadline, you need to follow through. Even if you accepted something with a ludicrous date, the deed is already done. This point ties to #9.When you accept any deadline, it is your responsibility to see it through (regardless of the time it takes). When you follow through on deadlines with clean code, you increase your trustworthiness, your reputation, and your value as an employee. You want to be the goto person and in demand. If you consistently getting low balled with deadlines, you need to assess your situation:

1. Are you estimating your due dates correctly? Do you have a good methodology for estimating man hours?
2. Have you educated your project owner about cutting corners? Have you given real world examples of how deviating from procedures can impact the bottom line?
3. If you feel you have sufficiently addressed the first two items, it is not out of the realm of possibility that you are being taken advantage of. At least you get a clear signal that the current position is not a good fit.