Posts filed under 'Personal Development'
The old joke has a guy asking pianist Arthur Rubinstein "Pardon me sir, but how do I get to Carnegie Hall?" and Rubinstein replying, "Practice, practice, practice." The question that novice programmers often ask is like it, "How do I become a professional programmer?" And, like the guy who only wanted directions they want to know which classes to take or certifications to earn to become a programmer. However, the real answer is that one must practice programming just like one practices the piano in order to master it.
How Do You Practice Programming?
The obvious way to practice is to write programs just like if you expect to learn piano you play the piano. But, it goes deeper than that. To learn, to effectively practice, you need to work on things that aren’t easy for you. For example, if you struggle with understanding how to write a good SQL Join, practice writing them until you get good at it. If the ins and outs of ADO.NET baffle you, work on them. Find areas that you’re weak in and practice them by writing actual working code.
Another way to practice programming, particularly when you’re learning a new language, is to take an algorithm that you wrote in one language and figure out how to write it in the new one. For example, if you’re transitioning to VB.NET from VB6, take some of your old code and figure out the .NET way of writing it. If you know VB.NET and want to learn C# or Java, do the same thing. You will find that this exercise not only helps you learn something new but also increases your knowledge of your original language.
Make Your Practice Structured
To make your programming practice more effective create a schedule or structure that you follow. For example, you might set a goal of practicing for 1 hour a week to improve your database coding and dedicate another hour in the week to learning something new. If you don’t set goals you’ll find that your practice becomes less and less until it doesn’t exist at all. It’s also a good idea to chart your progress so that you have hard evidence to yourself that you’ve achieved your learning goals. The sense of accomplishment when you do this is quite rewarding.
Practice While Working
You can practice while you work as well. The way I do this is to have a ’scratchpad’ program where I create little snippets of code. These often match my main work but this gives me a place outside of it to work through ideas without the overhead and distraction of the core program. Often you’ll find these little practice pieces will fit well into your existing program or even earn a place in the snippets plug-in.
Do you practice programming? If you do, what are some of your practice techniques? If you don’t, why don’t you? Do you have anything you would like to add or ask about concerning programming practice? If so, please leave a comment.
October 18th, 2007
A question that gets asked often by students trying to decide on a technical career is would programming be a good career choice. In recent tech site columns, like this one by Jason Hiner of TechRepublic, Sanity Check: Is IT still a profession worth recommending to the next generation?, and this one on WindowsITPro, Are IT Pros Steering Their Children Away From IT?, many commenters say that they would not recommend it. Let’s examine why this is a common response and the reasons behind it.
The number of jobs in the US for software development have been declining since 2000. Computer programmer employment has fallen from 530,730 in 2000 to 396,020 in 2006 according to the Labor Department. When inflation is factored in, salaries have also declined by about $850 a year since 2000 and continue to fall. H-1B visas and offshoring have contributed to this trend as have other economic factors. The sad truth is that the US software development industry is on the decline. No wonder there has been a decline in technical degrees, there simply isn’t any money in the field.
Then why do tech moguls complain that they can’t find enough programmers, you might ask. What they’re really complaining about is that they can’t find enough cheap programmers. Many older software developers are forced to work short term, temp, contracts to make ends meet. Rampant ageism in IT and the desire to hire the cheapest programmers possible prevents them from landing a perm position even while many well-heeled corporations lobby Congress for more H-1B visas because they can’t find enough (cheap) programmers.
All in all, the prospects for software developers in the US market isn’t good. If you want an IT career with some durability, then you should look a growth areas like network system administration or plan to quickly move from programming into a more lucrative and stable area such as project management or general IT management. If you have a love for programming, you might find it better financially to pursue it outside of work by contributing to an open source project.
However, in spite of all the negatives, there is one major good reason to pursue a programming career if programming is your passion. One of life’s greatest rewards is being able to enjoy your work because it really isn’t work to you. The best programmers I’ve worked with have had this attitude and are willing to continue programming in spite of career instability, crazy management decisions, brain-dead users and other such banes of a programmer’s life.
What do you think? If you already have a programming career would you do it all over again, knowing what you know about it now? If you’re a student, do you think your passion for programming is strong enough to make it in this field? Leave me a comment and let me know what your thoughts are on this issue.
October 11th, 2007
Do you feel like you are in a creative rut either as an individual or a team? How many sacred cows does your organization have? Are they holding you back in developing the best software you can? I started thinking about this after reading the US Navy Monkey Experiment article. Often in software development teams and individual programmers as well, invent sacred cows. These ‘cows’ can be a particular language, tool kit, or methodology. Eventually it gets to the point where the organization, or person, becomes unable and unwilling to adapt to change. Ultimately, it’s a self-defeating paradigm.
I see this a lot in teams and individuals who’re unwilling to move on from VB6. They cling to their sacred cow and refuse to consider alternatives whether it’s VB.NET, C#, Java, or something else. You’ll see this in the fervor some attach to the latest new methodology. The problem is that creative thinking is sacrificed to the cow. People get so locked into the approach they’re using that they’re unable to see the merits of alternative approaches. Like the monkeys in the experiment they attack anyone who tries something out of the norm.
Time for a BBQ?
Is it time that you turn your sacred cows into steaks? Here are some steps you can take.
1. Ask why are we doing things this way?
If you can’t answer this then you might be like the monkeys in the story, simply acting on what someone else told you without really knowing why. But, if you can answer it, then…
2. Ask does this reason still exists?
Maybe you know why you or your team started doing things this way but are the reasons for this still applicable? It may have been a good idea to start a new project in 1998 with VB6 but is it still a good idea in 2007? Perhaps a programming library worked well for Project A but it’s a burden to use it in Project B. Is it really a good idea to use it? Be willing to make some tough choices and stop paying homage to the cow.
3. Ask what are the pluses and minuses of continuing to do things this way?
There could be good reasons to continue doing what you’ve been doing. Are there? Once you’ve reached this point you should prepare yourself to honestly answer if the pluses outweigh the minuses or vice versa. At least by going through the exercise, especially as a team, you should be able to identify where improvement is needed. Sometimes only minor adjustments are needed but other times tougher measures may be required. Sometimes a destructive change, where old ways are discarded, can be helpful. Take the time to evaluate this possibility in yourself or in your team and see if it applies to you.
Let me know if you have made this kind of change or if you think this kind of change isn’t necessary by leaving me a comment. I would like to hear your opinions.
October 8th, 2007
Several of my recent articles have dealt with interviewing programmers. This time around I’m going to sit on the other side of the conference room table. I was given some of these interview tips from professional recruiters plus I’ve added some of my own observations drawn from my own experiences.
It is common these days for one to have upwards of 6 to 8 separate interviews with people of all different levels and positions. If you flub one part of the interview, then you may not get the job. Let’s look at dealing with these different levels/positions.
Dealing with Human Resources
These people are usually the gatekeepers of the company. Some act as your friendly tour guide to the company while others can be a bureaucratic nightmare to deal with.
The first type is easy enough to deal with, just be courteous and polite. Ask a few general questions that reveal your interest in the company. Don’t delve too deeply into benefits (for example, don’t ask “How are your substance abuse benefits?”) but ask reasonable questions about them. After all, you don’t want to be surprised by a lousy benefits package after you’ve accepted the position.
The bureaucratic type is the personification of Dilbert’s Catbert, a person who seems to take delight in tormenting interviewees and employees alike. They’ll have tons of legal paperwork for you to fill out, psych tests, and so forth. They’ll insist that you fill out a 5-10 page application by hand even though you have a perfectly good resume. They’ll talk about personnel plans like the vitality curve and other things that make employees miserable and at each other’s throats. Generally this person is on a power trip and this is usually a good indicator of a messed up company. Do you really want or need to work for this company? If so, grin and bear it. Otherwise, bow out gracefully and head for safety.
Of course there is a lot of room in between these two but the HR person will usually give you your best initial feel for the culture of a company.
Dealing with Non-Technical Persons
If you do interview with a non-technical person they’re probably going to be someone who you will be working with or for, either directly or indirectly, on the project that’s being staffed. Avoid getting deep into technical details but try to draw high level parallels between what you’ve done in the past and what they want done. For example, they’re wanting to build a document manager for insurance claims and you’ve done a similar project with auto loans. Let them know in confident, but not cocky, terms that you can help them due to your previous experience.
People in these positions are also good indicators of company culture outside of IT. Watch for warning signs of a dysfunctional organization or, hopefully, indicators that people really do like working there.
Dealing with Executives/Owners
When you interview with a member of executive management or, in smaller companies, one of the owners, it’s best to deal with abstracts when it comes to technology and dollars and cents issues when it comes to business. They’re going to be paying a lot of money for your time so you want to make sure you look like a good investment for the long term. Stick with topics like how your work has improved efficiency or increased ROI at your previous employers.
Mild flattery can help here too. Show them that you’ve researched their company by saying something like, “I noticed that you’ve been in business since 1996.” or “I read that you won the Human Fund’s Costanza award last year.” Just don’t lay it on too thick, they’ll see through it more than likely. Also, be careful about stumbling into something that might better be left unsaid. A faux pas at this level might kill your chances.
As for company culture, they usually aren’t the best indicator of it. They usually imagine that their employees are all happy campers and often don’t see cultural problems developing until it’s too late.
Dealing with IT Managers
Sadly, many of these people moved into management from programming, or another technical field like network administration, and, for their efforts, have become little more than bureaucratic paper pushers. They will generally be fans of processes, metrics and other busy work. The worst ones will be micro-managers and choleric jerks. Others will be nice but obviously lacking technically. Others, the good ones, will have technical savvy. You can generally get the feel for the situation quickly by seeing what kind of questions they ask and how they answer your questions.
If you’re being interviewed by Bill Lumbergh, you know it’s time to retreat unless you’re desperate for work. If you must stay in the battle, mention your love of metrics, well documented processes and your willingness to work on weekends.
The nice but non-tech guy/gal can usually be bedazzled by throwing out hot buzzwords like AJAX, Agile and Scrum, or just about anything else you can gather from the front pages of DZone, ZDNet or other popular tech sites as long as it seems to fit in with what they want to do. Don’t overplay your hand though because even if they aren’t up on things, somebody on their staff probably is and you may be called on it at some point.
The technically savvy manager, in most cases, will be your best or worse interview. It will be the best if you know your stuff and present yourself well, but the worst if you try to BS your way through. For the best results, treat them like you would a senior, knowledgeable, peer. If you impress them you’re more than halfway there.
Dealing with Other Programmers
These guys/gals should know both the technology and their problem domain. You may have a technical edge on them but don’t be a show-off about it. That’s a good way to get black balled. Listen attentively to what they say about their problem domain and, if given the opportunity, ask about a few details to show your interest. If you try to scam them with buzz words you’re very likely to fail and, if you do manage to dazzle them with BS, it probably isn’t the right place for you to be working anyway.
Remember that mess of an application or web site they share a few details about may be somebody’s pride and joy. Therefore, don’t talk about any design flaws you may notice without being invited to comment directly on them. Treat it just like you would treat a parent who just proudly presented you with a picture of their ugly baby. Likewise, if you’re awestruck by the perfection of their development methods you may want to find somewhere else to work if you know your skills aren’t up to the challenge.
Show them that you have a sense of humor but don’t go overboard into creepy, annoying or goofy territory. You want to be someone they wouldn’t mind hanging out with at lunch or after work. Smile and be friendly, even if it hurts.
If the programmers you interview with are obviously lacking in skill, this could be a warning sign. You may be handed the responsibility of improving things which can be a daunting task. If they hint at morale problems or other troubles, this should be a big red flag to you. Ask them to provide a few details about the work environment so that you can get a feel for what you may be getting into.
Ultimately, these people will usually be your best source for information about the inner workings of the company and will have a lot of control over the hiring decision their manager makes.
Well, this article went on for a little longer than I expected. I’ll have to follow it up later. Let me know if you thought these hints were helpful or not. Feel free to throw in your own hints and tricks and if you disagree with what I said. I always welcome your opinions and perspectives, even if they’re different from mine.
September 25th, 2007
Have you ever wondered what the salary difference is between a VB.NET and a C#, C++ or Java job? I did a little research on this tonight, courtesy of Indeed.com, the job listing aggregation site I have in my sidebar. What I found really wasn’t all that surprising but it was interesting none the less.
We’ll start off with what I found: A VB.NET programmer is worth roughly $6000 less a year than a comparable C#, C++, and Java programmer. This gap holds true across all job levels, entry level, mid-level, and senior. Here are screen shots of the aggregate numbers:
So, Should You, and I, Learn C#?
Over all, I think this salary gap is a perception thing. The management who sets the salary levels probably is comfortable with looking at VB code and thinks because it’s readable it must be easy. Likewise, they see a few curly braces and semi-colons in C#/C++/Java and think, “Oh, this must be hard.” Ultimately, it’s our job as VB programmers to show them that our skills and ability are on par with the others. That is certainly one of the goals I have in minds with this site.
Should you switch to C#? Well, that’s really a personal decision, but I think that there is great value in being comfortable in coding in either VB.NET or C# within the .NET framework. At the core, they really aren’t all that different. Outside the Framework, it is always helpful to your career and general programming skill to know multiple languages. Who knows when a Java or C++ algorithm might be helpful to your VB.NET application? Knowing how to translate it would be quite helpful to you.
My approach is going to be to always be in learning mode. If I’m learning something new, whether it’s in VB or C# or another language, I think I’m headed in the right direction. What’s you’re take on this? Is the potential for a $6k a year worth switching exclusively to C#? Leave me a comment and let me know.
September 17th, 2007