One of the things I like most about working in software development is the fact the for the most part you get to work with fairly intelligent people. I’ve always wondered why so many smart people manage their career so poorly.  If I had to guess, I would estimate that close to 35% of people in this industry don’t manage their career at all. Now I have a theory about why this is¹, but the fact of the matter is that explaining to that 35% the importance of managing one’s career is an utter waste of time. Today I want to focus on helping those who do manage their career, do so more effectively.

The key to understanding how to properly manage your career is to understand the importance of positioning, not where you are currently, but positioning yourself for growth (ie. You want to put yourself in a position of high growth potential).

The IT world changes so rapidly I nearly burst out in uncontrollable laughter the last time and interviewer asked me “What is your 5 year plan?”. Though its true things change so fast in IT that it’s difficult to plan long term, you should plan none the less. But your plan should be in terms of actions that will position you to take advantage of opportunities for growth; ideally those actions will also immediately contribute to your growth.

The two basic types of career growth are Professional Growth and Financial Growth.

Positioning yourself for Professional growth

Professional growth is generally thought of in terms of skill sets, you want to continue to improve on you current skills while acquiring new complimentary skills. Once you learn the basics of those skills you should put them to use on the job by asking for more responsibilities then a promotion.

Choose Skills that compliment your current skill set:

Because learning takes time and time is limited you need to ensure your time is well spent by learning skills that will best position you for growth. This is why it is so important to choose skills that compliment your current skill set. (If you already know C# WinForms learning ASP.Net will contribute more to you professional growth than learning Java.)

Having a large well complimented skill set does not make you a generalist; it makes you a well-rounded expert. Calling yourself a generalist implies that you can do many things at a mediocre level. Do not accept that label. Conventional HR wisdom is that you can only be an expert in one or two things. Don’t be afraid to challenge that, say directly and proudly, “I can do a lot of things, and I can do them well!”

Choose Skills that are transferable and Soft

Transferable soft skills should not be neglected; you should put as much effort into them as you do into learning hard skills. As you advance in your career you will find that Soft skills are of much higher value than Hard. Plus they don’t depreciate in value with time as tends to be the case with technical hard skills. Transferable skills are great because they complement so many other skills.

Skill	Hard\Soft	Very Transferable?
C# (Syntax)	Hard	No
Java	Hard	No
Sql Server Administration	Hard	No
DB Design	Hard	Yes
OOD	Hard	Yes
ANSII SQL	Hard	Yes
Business Knowledge	Soft	Yes
Industry Knowledge	Soft	Yes
Leadership	Soft	Yes
Time Management	Soft	Yes

 

Choose Skills that are Marketable

This is key, if you developed all the skills in the world but can’t put them to use, you accomplished nothing. As I stated above, once you learn the basics of those skills you should put them to use on the job by asking for more responsibilities then a promotion. If no such opportunity exists with your current firm you need to look for a new job that will put you in a position to take advantage of such opportunities.  This means you must choose skills that are marketable. By their very nature marketable skills have market value, which leads us to the second half of this article…

Positioning yourself for financial growth

Financial growth usually follows Professional Growth assuming you are in a position to take advantage of your Professional Growth to earn more money. If you have positioned yourself with a solid set of marketable hard and soft skills that complement each other well, you are off to great start. But you need one more thing: Negotiating Position.

To have a strong Negotiating Position you need to:

1)      Market yourself Internally (to your current Employer) and Externally to the Job Market

2)      Have Options and Know your next best Alternative should negotiations Fail and Know your Market Value

Marketing yourself internally

Even if you are happily employed you need to market yourself to your current employer. But because your job performance is under constant scrutiny at work, you need to be what you are selling. If you are marketing yourself as that employee who should be trusted with additional responsibility (as required for Professional growth) you need to be that someone who can be trusted with additional responsibility. You simply can’t fake this for long. You need to consistently do good work and act (and dress) professionally manner and ensure you are getting proper recognition for you work. I can’t stress this enough, you need to ask for additional responsibilities and then, when the time is right a promotion. If you get shot down, you should have a positive attitude and negotiate. “What do I need to do to ensure I get that promotion next January?” Then Follow up in December.. (But you better have lived up to your half of the bargain). If you are not happy with the results of these conversations or your employer is not living up to his end, you need to look for opportunities else ware.

You should act as if you care about the company and your job performance but like you don’t need the job. You want your employer thinking “If I don’t work with him/her, he/she may just up and quit on me.” You need to have a demeanor the projects a strong personality as someone who is not going to be taken advantage of (in a professional and respectful manner). Your demeanor should suggest loyalty but with limits.

One last point on this: You should market yourself internally even if you are sure you won’t be with the firm long term. When looking for a new job you really want to spend your time and find that job that will give you the growth you are looking for, and in today’s job market that could take well over a year. If you are that guy with a positive can do attitude, constantly improving yourself and taking on additional responsibility, no employer in his right mind would let you go. When layoffs are coming, these people are literally pulled aside and told “Don’t worry”.

Marketing yourself externally

Marketing yourself externally to the job market is a bit different than internal marketing. With external marketing you can literally outright lie about everything you ever did, and be met with some success. Doing so may get you a job, but once on the job you will never be given additional responsibly or a promotion, you will be first on the list come layoffs time, and quite frankly it’s dishonest.

Conducting a job search is simple (and outside the scope of this article): You need to have a plan, you need to put you plan into action and you need to reassess and refine you plan over time and iterations.

Options

If you are offered a new job or are negotiating a promotion with your current employer, you need to know your options if you are to effectively negotiate. That means you need to:

1)      Know your plan of action should negotiations fail.

a) If you are currently employed you always have the option of staying where you are while you continue to look. Don’t make the mistake of saying “

well this is better than what I have now”

b) If your plan is “Negotiations can’t fail” your plan is sh*t.

2)      Know how long it will take you to find another Job and at what salary.

a) If you are currently employed, the answer is “I have a job!”

3)      Know how long it will take you to find the job you want.

4)      Know what accepting this opportunity will mean in terms of long term growth.

5)      Know what accepting this opportunity will affect your external marketing strategy for your next job search. (In terms of skill set and position)

6)      Know your market value.

a) Think in terms of your whole skill set, you should be compensated for as much of your skills as possible. This is why complimentary skills are so important.

7)      Know how long you can go without income & how much you have in your emergency Fund.

8)      Know the Value of you current and proposed benefits package.

9)      Know your ability to do good work and market yourself internally once you accept the opportunity.

Knowing all of the above will enable you to negotiate stronger and with more confidence.  Don’t be afraid to negotiate everything and anything. You will come off as more confident, more capable and a more appealing Candidate. Not only that but you will be more confidant you made the right choice.

In Summary: Continually improve your skill set (hard and soft), Market yourself internal & externally, Have a plan, Negotiate.

Recommended reading

The Hard Truth About Soft Skills: Workplace Lessons Smart People Wish They’d Learned Sooner
Corporate Confidential: 50 Secrets Your Company Doesn’t Want You to Know—and What to Do About Them

¹So why do smart people do stupid things-A Moronic view of Free will
There’s an old saying: “God helps those who help themselves”.  But this is not quite true; it’s more of a half-truth. The full truth is “the ability to help ones self is the help God gives”. Unfortunately god doesn’t give everyone the ability to help themselves, for  those incapable, God has no choice but to help then directly as they are helpless. So I ask you, who is more likely to make a good decision? A) The smart helping themselves or B) The Stupid with God’s help?  Stupid people make quick decisions without thinking, smart people think things through, than choose wrong or choose inaction (analysis paralysis). Simply stated smart people have the free will to f*up, as God trusts them to act in a prudent manner.  “ … Key feature of stupidity is that its power lies in its abundance. One stupid person is helpless, a herd of stupid persons can be invincible….”

One of the very first ideas we had for this blog was to convert some of the wonderful gems of the early era of our site, the undisciplined period, to blog posts. Questions that were once enthusiastically received by the community, but no longer fit Programmer’s scope.

The first deleted question I’ve chosen is Jon Skeet’s “What’s your most controversial programming opinion?” question (available only to 10K+ users, sorry), a +391 scored question that was originally asked on Stack Overflow on January 2, 2009. What follows are twenty of the highest voted answers, in random order…

1. Programmers who don’t code in their spare time for fun will never become as good as those that do.

     I think even the smartest and most talented people will never become truly good programmers unless they treat it as more than a job. Meaning that they do little projects on the side, or just mess with lots of different languages and ideas in their spare time.

   by rustyshelf

2. Unit testing won’t help you write good code.

     The only reason to have Unit tests is to make sure that code that already works doesn’t break. Writing tests first, or writing code to the tests is ridiculous. If you write to the tests before the code, you won’t even know what the edge cases are. You could have code that passes the tests but still fails in unforeseen circumstances. And furthermore, good developers will keep cohesion low, which will make the addition of new code unlikely to cause problems with existing stuff.

   by Chad Okere

3. The only “best practice” you should be using all the time is “Use Your Brain”.

     Too many people jumping on too many bandwagons and trying to force methods, patterns, frameworks, etc. onto things that don’t warrant them. Just because something is new, or because someone respected has an opinion, doesn’t mean it fits all.

   by Steven Robbins

    

4. Most comments in code are in fact a pernicious form of code duplication.

     We spend most of our time maintaining code written by others (or ourselves) and poor, incorrect, outdated, misleading comments must be near the top of the list of most annoying artifacts in code. I think eventually many people just blank them out, especially those flowerbox monstrosities. Much better to concentrate on making the code readable, refactoring as necessary, and minimising idioms and quirkiness. On the other hand, many courses teach that comments are very nearly more important than the code itself, leading to the this next line adds one to invoiceTotal style of commenting.

   by Ed Guiness

5. “Googling it” is okay!

     Yes, I know it offends some people out there that their years of intense memorization and/or glorious stacks of programming books are starting to fall by the wayside to a resource that anyone can access within seconds, but you shouldn’t hold that against people that use it. Too often I hear googling answers to problems the result of criticism, and it really is without sense. First of all, it must be conceded that everyone needs materials to reference. You don’t know everything and you will need to look things up. Conceding that, does it really matter where you got the information? Does it matter if you looked it up in a book, looked it up on Google, or heard it from a talking frog that you hallucinated? No. A right answer is a right answer. What is important is that you understand the material, use it as the means to an end of a successful programming solution, and the client/your employer is happy with the results.

   by PhoenixRedeemer

6. Not all programmers are created equal.

     Quite often managers think that DeveloperA == DeveloperB simply because they have same level of experience and so on. In actual fact, the performance of one developer can be 10x or even 100x that of another. It’s politically risky to talk about it, but sometimes I feel like pointing out that, even though several team members may appear to be of equal skill, it’s not always the case. I have even seen cases where lead developers were ‘beyond hope’ and junior devs did all the actual work – I made sure they got the credit, though.

   by Dmitri Nesteruk

7. I fail to understand why people think that Java is absolutely the best “first” programming language to be taught in universities.

     For one, I believe that first programming language should be such that it highlights the need to learn control flow and variables, not objects and syntax. For another, I believe that people who have not had experience in debugging memory leaks in C / C++ cannot fully appreciate what Java brings to the table. Also the natural progression should be from “how can I do this” to “how can I find the library which does that” and not the other way round.

   by Learning

8. If you only know one language, no matter how well you know it, you’re not a great programmer.

     There seems to be an attitude that says once you’re really good at C# or Java or whatever other language you started out learning then that’s all you need. I don’t believe it- every language I have ever learned has taught me something new about programming that I have been able to bring back into my work with all the others. I think that anyone who restricts themselves to one language will never be as good as they could be. It also indicates to me a certain lack of inquistiveness and willingness to experiment that doesn’t necessarily tally with the qualities I would expect to find in a really good programmer.

   by glenatron

9. It’s OK to write garbage code once in a while.

     Sometimes a quick and dirty piece of garbage code is all that is needed to fulfill a particular task. Patterns, ORMs, SRP, whatever… Throw up a console or web application, write some inline SQL (feels good), and blast out the requirement.

   by jfar

10. Print statements are a valid way to debug code.

      I believe it is perfectly fine to debug your code by littering it with System.out.println (or whatever print statement works for your language). Often, this can be quicker than debugging, and you can compare printed outputs against other runs of the app. Just make sure to remove the print statements when you go to production (or better, turn them into logging statements).

    by David

11. Your job is to put yourself out of work.

      When you’re writing software for your employer, any software that you create is to be written in such a way that it can be picked up by any developer and understood with a minimal amount of effort. It is well designed, clearly and consistently written, formatted cleanly, documented where it needs to be, builds daily as expected, checked into the repository, and appropriately versioned. If you get hit by a bus, laid off, fired, or walk off the job, your employer should be able to replace you on a moment’s notice, and the next guy could step into your role, pick up your code and be up and running within a week tops. If he or she can’t do that, then you’ve failed miserably. Interestingly, I’ve found that having that goal has made me more valuable to my employers. The more I strive to be disposable, the more valuable I become to them.

    by Mike Hofer

12. Getters and Setters are highly overused.

      I’ve seen millions of people claiming that public fields are evil, so they make them private and provide getters and setters for all of them. I believe this is almost identical to making the fields public, maybe a bit different if you’re using threads (but generally is not the case) or if your accessors have business/presentation logic (something ‘strange’ at least). I’m not in favor of public fields, but against making a getter/setter (or Property) for everyone of them, and then claiming that doing that is encapsulation or information hiding… ha!

    by Pablo Fernandez

13. SQL is code. Treat it as such.

      That is, just like your C#, Java, or other favorite object/procedure language, develop a formatting style that is readable and maintainable. I hate when I see sloppy free-formatted SQL code. If you scream when you see both styles of curly braces on a page, why or why don’t you scream when you see free formatted SQL or SQL that obscures or obfuscates the JOIN condition?

    by MustStayAnonymous

14. UML diagrams are highly overrated.

      Of course there are useful diagrams e.g. class diagram for the Composite Pattern, but many UML diagrams have absolutely no value.

    by Ludwig Wensauer

15. Readability is the most important aspect of your code.

      Even more so than correctness. If it’s readable, it’s easy to fix. It’s also easy to optimize, easy to change, easy to understand. And hopefully other developers can learn something from it too.

    by Craig P. Motlin

16. XML is highly overrated.

      I think too many jump onto the XML bandwagon before using their brains… XML for web stuff is great, as it’s designed for it. Otherwise I think some problem definition and design thoughts should preempt any decision to use it.

    by Over Rated

17. Software development is just a job.

      I enjoy software development a lot. I’ve written a blog for the last few years on the subject. I’ve spent enough time on here to have >5000 reputation points. And I work in a start-up doing typically 60 hour weeks for much less money than I could get as a contractor because the team is fantastic and the work is interesting. But in the grand scheme of things, it is just a job. It ranks in importance below many things such as family, my girlfriend, friends, happiness etc., and below other things I’d rather be doing if I had an unlimited supply of cash such as riding motorbikes, sailing yachts, or snowboarding. I think sometimes a lot of developers forget that developing is just something that allows us to have the more important things in life (and to have them by doing something we enjoy) rather than being the end goal in itself.

    by Greg Beech

18. If you’re a developer, you should be able to write code.

      I did quite a bit of interviewing last year, and for my part of the interview I was supposed to test the way people thought, and how they implemented simple-to-moderate algorithms on a white board. I’d initially started out with questions like:

    Given that Pi can be estimated using the function 4 * (1 – 1/3 + 1/5 – 1/7 + …) with more terms giving greater accuracy, write a function that calculates Pi to an accuracy of 5 decimal places.

      It’s a problem that should make you think, but shouldn’t be out of reach to a seasoned developer (it can be answered in about 10 lines of C#). However, many of our (supposedly pre-screened by the agency) candidates couldn’t even begin to answer it, or even explain how they might go about answering it. So after a while I started asking simpler questions like:

    Given the area of a circle is given by Pi times the radius squared, write a function to calculate the area of a circle.

      Amazingly, more than half the candidates couldn’t write this function in any language (I can read most popular languages so I let them use any language of their choice, including pseudo-code). We had “C# developers” who could not write this function in C#. I was surprised by this. I had always thought that developers should be able to write code. It seems that, nowadays, this is a controversial opinion. Certainly it is amongst interview candidates!

    by Greg Beech

19. Design patterns are hurting good design more than they’re helping it.

      Software design, especially good software design is far too varied to be meaningfully captured in patterns, especially in the small number of patterns people can actually remember – and they’re far too abstract for people to really remember more than a handful. So they’re not helping much. And on the other hand, far too many people become enamoured with the concept and try to apply patterns everywhere – usually, in the resulting code you can’t find the actual design between all the (completely meaningless) Singletons and Abstract Factories.

    by Michael Borgwardt

20. Less code is better than more!

      If the users say “that’s it?”, and your work remains invisible, it’s done right. Glory can be found elsewhere.

    by Jas Panesar

What do you think? And more importantly, what’s your most controversial programming opinion?

Update

A few more controversial programming opinions:

• Hopefully More Controversial Programming Opinions, by James Hague,
• 12 (Really) Controversial Programming Opinions, by Bill the Lizard.

Some time ago, the development team at my firm staged a revolt against the sales team and senior management: our demand was that no Statement of Work was to be sent to a customer without first being reviewed by a member of the development team.

The message was clear: “We refuse to be held responsible to deliver on terms in which we had no say”. Today it’s not uncommon for a senior member of a development team to author a SOW in its entirety. In many ways they are better equipped than sales staff to write a SOW. They are good with documents (questionable), are very detail oriented, are great at finding loopholes, and at breaking down large ideas into small, manageable chunks. Today I would like to explore an important aspect of any Statement of Work: the pricing model.

Though there are countless pricing models in use throughout the world, the two that are most prevalent in the IT world are:

• Fixed Price (also referred to as Fixed Fee)

Both the price and the scope of work are set in the SOW and neither change without agreement from both parties. I, (seller) will provide you (buyer) with X, Y and Z in exchange for $A.

• Time and Material (T&M)

The buyer agrees to pay a set amount per hour plus the cost of materials and other expenses. I, (seller) will provide you (buyer) with X, Y and Z in exchange for $A per hour of effort needed to produced, Y and Z. You (buyer) will also reimburse me (seller) for any expenses I may incur (Hardware, travel etc.).

The major difference between these two is who bears the risk if you exceed the estimate. With Fixed Price, it’s you the IT professional who bears the risk. With T&M it’s your client. Regardless of what pricing model you choose, you will need to estimate what it will cost to perform the work (even with a T&M contract the client is going to want an estimate before signing it). As the professional, it is you who are responsible for the estimate, and logic would follow you should stand by your estimate and accept responsibility if it is off.

That said, any time you take additional risk you should be compensated for it. As a rule of thumb I would recommend charging a 20% premium on a fixed price contract over a T&M one. So the same contract under a T&M pricing model (assuming you are spot on with your estimation) will be 20% less than a fixed price one.

Based on the premise above, I propose the following: You should adopt a policy of always choosing Fixed Price over T&M unless you have a good reason not to. Before I delve into the details of what exactly is a good reason to choose T&M over Fixed Price, I want to dispel a few myths:

Myth: Risk is bad

Fact: Risk is an opportunity to make (or lose) money. It’s neither good nor bad. As I have stated above you can easily earn 20% more just by accepting the risk associated with your own estimate.

Myth: T&M pricing protects you if you exceed your estimate.

Fact: If you exceed your estimate, even with a T&M pricing model your client will fight you tooth and nail over the overage, even small overages (This is even more true in today’s world of tightened budgets). Often he will refuse to pay above the estimate forcing you into a compromise. Getting new business from this client will be substantially harder next time.

Myth: With T&M you don’t need a change control process.

Fact: You will need to show hard evidence explaining why your estimate was wrong. The only evidence worth anything is client signed change control documents that clearly outline the cost of the change.

Myth: With T&M, the client benefits if you are under your estimate.

Fact: Consulting firms will simply not leave money on the table.

Myth: Incompetency in your firm’s ability to accurately estimate is a good reason to choose T&M

Fact: Unless you are upfront with your client about your inability to estimate a project choosing this reason for T&M is unethical. You (your firm) are professionals; you sold yourself as experts with statements like “We’ve done this kind of stuff a hundred times before!” If you cannot properly estimate a project, you have no right to call yourself experts on the subject matter. If you would never tell your prospective client the real reason you are proposing T&M, your reason for choosing T&M is simply not valid, and likely unethical. You did the Estimate, you are the expert, and it’s your job to know how long it will take and what problems may arise. (I’ll say it a second time: You are a professional; accept responsibility for your estimates)

Myth: Double your estimate, just to be safe.

Fact: This myth comes in many varieties, which can range from adding 15% to quadrupling your estimate. The truth is, doubling your estimate will simply make your bid uncompetitive (or unrealistic), and you will lose the contract to a competitor. (Three’s a charm: You are a professional; accept responsibility for your estimates)

Myth: Developers don’t need to know the pricing model.

Fact: Everyone on the team needs to know the pricing model. It effects every decision the team makes that involves effort. Who is paying for the effort is always a factor in such decisions.

Okay, so what is a good reason to choose T&M? A good rule of thumb is “If you are unable or unwilling to give your client a solid estimate AND you can explain the reason you can’t (or won’t) in a way your client will understand and respect you should go with T&M”. Keep in mind that just because you can’t (or won’t) estimate a particular task, doesn’t mean that the entire SOW must be T&M. You can specify T&M for some tasks and Fixed price for others). Here are the most common examples:

• Insufficient data to properly estimate it: Your client is asking you to migrate data from an internal proprietary system to a new system you are implementing. Your client says the data is clean and properly normalized. Because you have nothing other than your client’s words to go on, your client should accept the risk of his information being wrong.

• Your client wants to take part in the project in any way: If he is providing resources (ie internal developers or another vendor is participating that the client is managing) or if you are working on site, you should go T&M. You should not be held accountable for the performance of your client’s resources where you are obligated to ensure they succeed. Chances are high that you will wind up performing this work in its entirety, while fearing to tell the client that his trusted employees are incompetent.

• Your client has a culture of excessive meetings and bureaucracy: This kind of culture tends to exist with larger fortune 500 type firms. The only way to work with this kind of client on a fixed price basis is to specify in the SOW exactly what kind of documents will be submitted and how many hours of meetings will be attended. Often the client has to do days research just to get you a list (and templates) of documents that need to be submitted in order for the system to move from one environment to another. Unless you have a history with the client this is hard if not impossible to estimate.

• Your client insists on T&M: This usually happens after you have built a relationship with your client; he trusts you and no longer wants to accept the risk and rewards (the 20% discount) of T&M.

• Your client is looking for a support contract: With support contracts, instead of defining specific work to be done, only the type of work to be done is specified, and it is performed as needed.

The last point I want to make is this: if you are bidding on a very large project I would strongly suggest that you split the project into phases with separate contracts. The first phase will deal with requirements gathering and system design. Once that phase is done, you will be in a much better position to properly estimate the effort required for the development phase.

When your estimates are accurate everyone wins.

There was a great question on Programmers about graduating with a programming degree, but not knowing how to program. I see this kind of question a lot, and I felt the same way when I first got my degree, so I thought I’d write about my experiences and what I learned when first started programming.

Start with baby steps

First off, don’t expect to be able to code enterprise-level applications or the next Facebook right away. You really can’t become a good programmer without a lot of practice, so practice any way you can. This can include hobby projects, reading books or source code, or even answering questions on Stack Overflow.

The book Outliers: The Story of Success frequently states that to become a master in any field you need to practice it for a total of 10,000 hours. In case you don’t want to do the math, that’s about 3.5 years of programming 8 hours every single day. If you only program during business hours at work, that’s almost 5 years.

Don’t discount your education

When I first started working, I felt my education was worthless; that it just taught me stuff that was never used in the workplace. I soon realized it provided me with something better than syntax: it provided me with a good foundation for programming. For example, it didn’t teach me design patterns, but it did teach me what design patterns were and how / when to use them. And I might not have built a data access layer in my class projects, but I knew what they were for and when to use them.

It also provided me with resources such as books, an online library, and networking contacts in the industry. In addition, it gave me a fancy piece of paper which can be very useful for getting your foot in the door when you don’t have experience.

Of course, it didn’t teach me everything. Looking back, I wish I had been taught about things like Version Control and Unit Testing. But the institution did their best to provide me with a solid foundation to build upon in the short time I was there, providing I was willing to go out there and keep learning.

Always be learning

One of the first things I got taught in college was that to be an IT professional, you really need to be a life-long learner. You can’t just graduate and expect you’ll have everything you need to get a high-paying job for the rest of your life. You’ll need to be willing to spend the rest of your life learning new technologies and languages.

Whenever I come across something new, something I don’t understand, or something I’m not sure of how to do, I Google it. Most of the time I can find a simple definition or samples, and I can start from there. If I do start from samples, I hate just blindly copying/pasting. I always take the time to understand what the code does. It might be slower to start with, however once understood it makes me that much better of a programmer.

Remember, N years of experience means nothing if it was simply 1 year repeated N times. There are plenty of jobs out there that are that will let you accumulate years of experience without you ever needing to learn anything new, however I feel you simply cannot be a great programmer without continuing to learn.

Steps to success in programming projects

Here is a list of steps to success in any project as a new programmer:

• Be positive when asked if you can do something.
  
  

  If someone asks you if you can do something, be positive in your response. Answering negatively, or even indecisively, will often result in a lost opportunity to learn and grow, so avoid that unless the task is truly outside the realm of possibility.

  I usually use terms like “I don’t see why not” or “shouldn’t be too hard”. You may not know how to do it right away, but you should have the tools (Google!) and intelligence needed to figure out how to get it done. I like to avoid actually saying “yes” unless I know I can actually do what is being asked.

• Determine requirements.
  
  

  Sit down with your client (boss, customer, etc) and figure out what they want. I’m not going to go into details of gathering requirements here, but do take the time to draw out the screens they expect to see, and to determine the expected input / output. My favorite tool for screen mock-ups is Balsamiq.

• Figure out how to build it.
  
  

  This is one of the most important steps. A huge part of programming (especially early on) is figuring out what your client wants, and then learning how to do that. Don’t just stick with your own knowledge base!

  For new programmers, I would suggest just focusing on just getting the desired results. Don’t get bogged down trying to learn design patterns, architecture, test-driven development, etc. Learn the basics of how to program first, then expand on that knowledge. And remember, keep it simple! You don’t need an enterprise-level solution for the FizzBuzz problem.

  At this point, if you determine that the project is completely out of your scope, say so. Even if you determine the project is far too large or complex for you to build, you will have at least increased your own knowledge, so I always see it as a win-win situation.

• Build it.
  
  

  You might think this is the hardest step of all, but in reality it will eventually become one of the easiest ones. Gathering the requirements and figuring out how you’re going to build the application are much more important, and if done right, it will make this step a breeze.

  Of course, early on in your career this step will be the most time-consuming and frustrating one. It will likely consist of a lot of trial and error, but don’t be disheartened because this means you are learning! We learn much more from our mistakes than from our successes, and the more you learn, the better your programming skills will become.

Summary

So to summarize, don’t worry too much about not being able to build/understand enterprise-level applications straight out of college. Start small, and keep an always be willing to learn. Work on programming for results first, and worry about best-practices later on. Hobby projects are a great way to gain experience. And remember, don’t ever stop learning!

Each year the Belgian Microsoft Innovation Center (MIC) runs a program to introduce future graduates in software development to local startup companies. The students come with their enthusiasm and eagerness to learn; the Startups arrive with innovative and exciting projects and the MIC provides the infrastructure and support. This year I had the pleasure to manage 24 students over 19 projects. I’ll explain how we did it.

In addition to the equipment necessary for project implementation (laptops, office, subscriptions, software, etc…) we organized many activities. The purpose of these activities was to increase significantly the level of our future developers’ professionalism while ensuring the proper conduct of the projects for our local businesses. These activities included among others: training, collective code reviews, coaching and each trainee had to give presentations.

Training

There was nothing very special about the training except the emphasis we gave to interactivity. One thing we noticed was that instead of covering new topics we were trying to complete the learning that students had achieved during their studies. Here are some of the topics we covered:

• Coding guidelines
• Source code controllers (We used Mercurial on BitBucket.org)
• Unit Testing
• Design Patterns
• C # in depth (inspired by the book of the same name)
• Agility in general
• Scrum in detail
• Effective Logging & debugging
• Basic concepts of project management software such as backlog management

We believe that these issues need to be fully integrated into university/college curricula. This would allow us to focus on even more advanced subjects.

Collective Code Reviews

I regularly organized what we call a collective review of the code. This does not mean that everyone read all the code – that would be inefficient.

I read each trainee’s code and when I came across a problem, I would put a screenshot on a powerpoint slide. The next slide was a copy of the previous slide but with arrows showing the errors and a third slide was a screenshot of the code as I would have liked to have seen it. One type of error was added to the presentation once. For example, “poor management of exceptions” was examined only once even if it was a widespread problem found in most projects.

All the students would gather in the conference room to see the presentation. For each problem the first slide is shown so that the group could review it and identify potential problem with the code. Very often, one of the interns suggested the right solution straight away. The slide that highlighted the errors was then displayed and a discussion took place. Finally an example of corrected code was shown (third slide) so that everyone would get the benefit of the “lesson”.

Occasionally, good practice was suggested which always generated discussions and suggestions.

The learning method proved very effective. Students loved the performance aspect since it is very interactive and it always close to the problems they face.

Coaching

In addition to formal learning, intensive coaching has been implemented. At any time, I could intervene to help trainees to advance the project. I was fully dedicated to that during the whole period. They also had the opportunity to come and see me to ask technical questions whenever they could not find a solution online in less than 10 minutes (on Stack Overflow for example). Rather than handing out fish, the technique of coaching was to teach them how to fish. We placed an emphasis on developing the student’s capacity to learn while giving them the ideal conditions for the rapid acquisition of new knowledge. Coaching also included informal learning and covered all the things that are more difficult to cover during presentations to the group. Here are the different subjects which have been covered:

• Continuous integration
• Blogging
• The use of a project tracking tool (we used Trello see below)
• How to write an effective resume
• How to interview
• How to gain certifications (Microsoft )
• The attitude to adopt in the business environment

The last point was particularly important to me. Throughout the internship, I stressed the one point that I think will make the difference between them and other developers: the ability to solve problems and not create new ones.

Project Monitoring

Managing the project was a very important part of the project. In fact, following 24 people in 19 projects is not an easy task. We naturally chose to set up Scrum and used a task management tool of the kanban type. Trello was chosen for its ease of use.

We formed four “virtual” teams based on project similarities, included in these “virtual” teams were two real teams of 2 or 3 people, Alongside our desire to maximize the output, we had a secondary objective to get the trainees to live Scrum and agility in general through real scenarios, some exactly as in a large company. So we had the daily scrum, the sprint review, the retrospective and a lighter version of the sprint planning.

Scrum has proven very effective in this type of program. We plan to integrate even more companies in the process. Although I took the role of “Product Owner” on this occasion we think it would bring more if the course tutors played this role, after training.

Trainee presentations

Students had the opportunity to prepare and make presentations to the group of students. These presentations were in addition to what was originally planned in the program and has allowed the students to practice the art of presentation but has also allowed them to share their new learning with the other trainees. Subjects covered were:

• Introduction to HTML5
• MEF (Managed Extensibility Framework)
• Work with Blend interfaces
• Introduction to Windows 8
• Introduction to XNA
• Introduction to ASP.NET MVC
• Deploy a WCF service in Azure
• Object Mocking
• Get organized with GTD
• The pattern MVVM
• Introduction to Programming Kinect
• Which company to choose?
• Introduction to Silverlight
• Debugging with Visual Studio.

We believe that a great developer must learn to communicate his knowledge and this exercise is therefore one of the things we will continue in the future. Indeed, in addition to these presentations, we encourage our trainees to develop a presentation video by making the appropriate equipment available. In business, those who are able to communicate well are often those to whom we entrust the most responsibility.

Conclusion

How will we know if this program will lead to better performance from the students in comparison with other internship models? That’s the question we asked ourselves last year.

This year we have developed a proficiency test that measured several dimensions that we believe a developer must master. As we predicted, the score at the start of the program was pretty bad. At the end of the course this score had, on average, doubled!

Despite this result, we cannot say today that our program will have had an effect significantly superior to another approach, simply because we did not have a control group. We hope to do this in 2013.

I sincerely hope that other companies will be inspired to create a similar program within their specialism. I am also very interested in any form of feedback or to hear of your experiences – you can contact me in the comments.

You can see a video introduction to the program here.

In addition, one of the project participated in the Imagine Cup 2012 and you can watch the video here.

 

Programmers have to work with large amounts of bad code. Sometimes its your own code, but other times its another programmer’s code. If you have to frequently work with another programmer’s bad code, you will eventually wish to approach them about their code quality, however how to do this without causing offense or resentment is not always easy. This article is about the approach I would take when wanting to casually talk with another programmer about their code quality.

Determine the problem

First off, determine what exactly the problem is, and verify that it is worth bringing up. Ask yourself:

• Do you work with this person on a regular basis?
• Will you be working with, and maintaining their code in the future?
• Is this an actual problem that harms productivity, performance, or security, or is it simply a case that your preferences are different from theirs? For example, simply complaining that “your naming convention doesn’t match mine” is not a very good reason, however saying “your naming convention makes it hard to understand what is going on in the code” is a much better.

If you answered yes to all of those, then it sounds like you might have a good reason to approach someone about their code quality.

Gather your arguments

Once you’ve determined there is a valid reason for trying to change the way another programmer does things, get your arguments prepared. Identify why the code is harmful to the development environment, and figure out the ideal way of coding it instead. Pick some code samples illustrating the problem, and write your own way of coding the same piece. Determine what your arguments are for why your code is better than the existing code sample. Don’t use arguments such as “it’s best practice”, but instead explain why it’s a best practice (readability, maintainability, reusability, etc)

Approaching the other programmer

Now that you know your arguments for why you think your code is better than theirs, and have a clear idea of what the ideal code should look like, arrange a time to talk with the other programmer.

This could be a casual conversation, or it could be setting up an appointment to talk with them about your concerns. How you choose to approach your co-worker is based on your level of comfort with them, the organization’s environment, and both of your ranks within the organization. For example, if I wanted to talk to the programmer next to me, I might simply ask them if I could have a moment of time whenever they’re available to talk with me about a piece of code, however if it’s my boss, I might send him/her an email asking if I could setup a brief meeting with them to discuss some code I’ve been working on.

Some people might argue that approaching a boss is different than approaching a co-worker, however I feel they are both people and both deserve equal respect. The only real difference I see is that your boss’s time is usually more valuable to the company, so be aware of that when talking with him/her.

What to say

When you actually talk with the other programmer, I usually find a good way to start the conversation is to ask them to explain their code. Ask if there was a reason for their style of coding, or tell them you’ve never seen something coded that way, and ask them why they chose that method. Really listen to what they have to say during their explanation. It could be that their way is right, and you are wrong, in which case take notes and learn from it!

If you still think the code is bad and worth changing, show the other programmer how you would code the same piece of code, and tell them why you would code it that way over his/her way (better performance, fewer chances of errors, easier for other programmers to read/maintain, etc).

Focus on why your method of coding is better, and not why their method is worse. Nobody likes being accused of writing bad code, although in reality we were all new once and I’m sure we’ve all written some horrendous code at some point in our lifetime. Be sure to keep the conversation focused on the code, and avoid turning it personal by talking about the person who wrote the code. It is always best if you can show that you understand that sometimes bad code gets written, whether it was due to time constraints, inexperience, or simply a bad day.

In addition, don’t try and get them to change their old code (unless you are their boss and want them to spend time doing so). Your goal is to educate them so they stop making the same mistake in the future, not berate them over past mistakes and punish them by extra work.

Afterwards, see if he/she still supports their coding style over yours. If they are open to improvement, they will likely change their way of coding going forwards. But if they still prefer to use their coding style, you are not likely to change their opinion, so drop the subject and don’t bring it up again unless their code is actually harmful.

Conclusion

Remember, nobody can write perfect code, and good programmers are always looking for improvement. The world of programming is so big that its impossible to know everything. It’s very likely that the other programmer doesn’t know there is a problem with their code, and would appreciate the input, providing you do it in such a way that you are teaching them, and not insulting them.

So don’t be afraid to approach another programmer about their code quality. I know I would appreciate the conversation, and I think you would too.

Congratulations to Programmers.SE. We just finished our first contest, and we’re still rolling. For those of you who want to know a little bit more about the contest, here we go…

The Beginnings

To develop this contest proposal, we first opened up the chat room (Contest Consipracy room). We did a little bit of talking and chatting, bouncing ideas off of one another, but we didn’t get too far. So, we decided to post this: Programmers.SE Contest: New Proposal. In this Meta post, we asked for ideas as to what the contest should be about. Whatever idea had the most upvotes would win. This way, the general community as a whole would be able to decide what they wanted their contest to be like, because that’s how it’s supposed to be. This is your site, powered by  your questions and answers we’re talking about here. We had a winner.

Developing the Details

Basically, after the contest structure itself was picked, we had to pick what tags we were going to use, and what prizes we were going to give. For that, we went back to Meta, and posted Books for Programmers Contest. There were two things wrong with this:

1. This meant that all you could get was books.
2. People were choosing (and upvoting) books that most (or at least a lot) of users already had.

So we went back to the chat room, talked to a few SE employees, and came back with a new idea. This idea was that you were allowed to pick any programming related thing(s) from Amazon, as long as your total was less than or equal to $50 (about €40). Cool right! After we got that situated, we went to Meta again, and finally posted the following: Programmers.SE Contest: The Complete Outline. This was the final outcome of the communities work.

The Winners

I’m not going to go into too much detail on this, as full results can be found here. But here are all of the winners of the contest:

The Aftermath

After the contest, we asked the community what we did right, wrong, and for good old feedback. What we got was just that, great feedback. I don’t mean everybody said that we did everything right (I can assure you of that), but it was very good constructive criticism, and that’s exactly what we were looking for.

Conclusion

All in all, I think the contest was a great event for our community. And I love the fact that we were able to do it. Now, you may be asking, is this the last contest we are going to have? Well, as long as we get enough community support, of course not. Heck, maybe you’ll be the one to propose the contest next time. Did you know Programmers.SE’s birthday is December 16th? Maybe we can have a birthday celebration. Who knows?

What we do with the site is up to the users. Without the users, there would be no Programmers (and that would be very sad). So if you have an idea, make a Meta post about it, or drop by The Whiteboard and see if others would be interested.

I hope everybody had an enjoyable time with the contest. Next time, we’ll make it even bigger and better!

Introduction

A quick search for the words “bad code” and “code smell” on Programmers Stack Exchange fetches a lot of results. So this means that several people are having this problem. This article present a few ways to work with this problem from a non-technical 30000 feet perspective.

A few caveats

• Nobody can write perfect software; you can improve it forever. There is always room for improvement.
• Programs keep changing based on requirements and requirements based on market environment. Hence code is dynamic and prone to error.
• Bad code is not directly proportional to programmer inefficiency. There are a lot of other factors that contribute to bad code.
• This article is written from the perspective of enterprises engaged in the business of software.
• In my opinion, there are a few hopeless cases where you just cannot tame it. A list of them is given at the end of the article.

What is bad code?

Though difficult to define, for the purpose of this article, we can define bad code as some piece of code that is: incomprehensible by reasonable standards,¹ lacks in conceptual integrity, doesn’t have a definite structure and is a sign of more bigger problems. Technically, code smell.²

If a bad piece of code is not found, it can quickly turn into a code smell and transform into a black hole that could suck every good part of the program in.

The following are a few explicit instances of bad code

• the person who wrote or maintains the code cannot explain it in a logical manner
• changing one part of a program breaks another
• improper documentation
• lack of conceptual integrity
• lack of standard conventions
• lots of duplicated code
• too many components to integrate and too many layers

Causes for bad code

The causes for bad code are many and the reasons are also multidimensional. So, causes may be viewed from three main perspectives:

Programmer-centric

• Improper communication³
• Lack of domain knowledge⁴
• Lack of experience and understanding
• Lack of experience in a particular tool-set or methodology

Design/Architecture-centric

• Anti-patterns
• Over-engineered code
• Interface kludge
• Lot of individual components to integrate
• Improper layer/tier separation
• Improper selection of technologies
• Anemic models

Organization-centric

• Outdated methodologies
• Outdated tool-sets
• Usage of legacy systems
• Too much vendor lock-in
• Wrong hiring policies

There are several other ways that bad code can be made, and each topic in this list deserves a separate article on its own. The following Wikipedia page provides some excellent links.

Ensuring the code is indeed bad

Before embarking on this journey, make sure that the code is indeed bad and it needs to be taken up. The following guidelines would help.

• Do plenty of research and get to the root cause.
• Analyze the code from multiple perspectives. Review it with another person.
• See old versions of the code to know its evolution.
• Always use objective standards.
• Discard petty issues, obvious errors that could be easily corrected.
• If possible, correlate between the code and the bugs created by the code.
• Use standard code coverage tools to analyze the program.

Your Rank in the organization

A program is just not an entire technical pursuit. There are different priorities for the same program at different ranks and the same technique wouldn’t be a good fit for all.⁵ Thus your rank in the organization gives you the ability to leverage your resources purposefully. The higher the rank, the higher the resources and the bigger your influence albeit with higher responsibility. Enterprise hierarchy is one big tree you can’t always traverse successfully.

For the sake of simplicity, we assume three ranks in the hierarchy bottom-up.

• Rank 1 – people who actually write code – programmers, developers, software engineers – scope limited to a module or a set of modules.
• Rank 2 – people responsible for a project – Project leaders, senior developers, team leaders, software architects – scope covers the entire project in hand.
• Rank 3 – people responsible for the delivery of the software to the customer and revenue to the organization – Project managers, Product managers, delivery managers – scope extends to the successful delivery of the project.

There is a correlation, though not directly proportional, between rank and the nature of problem. Most programmer-centric problems can be attributed to Rank 1, design-centric to Rank 2 and organization-centric to Rank 3.

A few suggestions to approach the problem:

• Know your position and rank in the organization and approach problems that could be realistically solved by you. You may easily talk to a co-worker about refactoring but you can’t expect to implement it across teams if there are tight deadlines. Be pragmatic as what you could solve.
• Talk to the right person. Know the scope and rank of the person you are talking to. You can’t discuss design or methodology change with a Rank1 programmer nor you could be talking variable naming conventions with your boss.
• Take time off. A prior appointment would be good. Never ever discuss in a urgent, haste manner. Proceed on a case-by-case basis. Remember you are pitting for a future change and people doesn’t like change.
• Always give time for reasoning and listen to the person you are talking to and never run into an argument on his style of programming.⁶
• Despite your best efforts, if your underlying assumption about the code turns to be wrong, graciously accept it.

The following additional guidelines would help for different ranks

Rank 1 Communication

A person in this rank may not be fully aware of the entire software life-cycle. So you are limited about what things you could talk to but this is the rank where most of your suggestions would be accepted. Communication is the X-Factor at this rank.

• Know the qualification, domain experience, expertise and the programming paradigm of the person. Paradigms (Object Oriented,Functional) and domain experience play a huge role in programming style and understanding. Ascertain the right area of concern.
• Ask him to explain the code to you and share your thoughts about it. Show how your proposed method could be better. Use an objective method to stress the advantages arising out of the new method versus its disadvantages.
• Put focus on ease of use, easy maintenance, long-term development of quality software and stress the importance of cascading effects
• Don’t talk things beyond his reach. He is just hired to do programming not to run the organization.

Rank 2 Communication

Persons in this rank do have a lot of technical knowledge so you got to be spot on with your reasoning and facts. Also, keep all your discussions at the conceptual level. Changes at this level may take time to get implemented. Clarity is the X-Factor at this rank.

• Ask the reasons for choosing the specific design or architecture; the constraints, advantages and trade-offs involved.
• If the design is flawed, pinpoint it accurately. If it is a known anti-pattern, name it precisely. If there is a flaw in the business logic, describe it with the industry standards.
• If the design, though technically sound, is too esoteric, try explaining how making it a bit simple would make it more easy.
• Building a good design takes considerable time and energy. So try concentrating on improving the existing design to rectify the flaws rather than proposing a radically new design.

Rank 3 Communication

You are operating at a much higher level where revenue is the main priority. You must prove decisively that the present polices inadvertently lead to programmer inefficiency and thereby increasing cost. So, a lot of work needs to be put in. Remember, you are pitching for a future organizational change. Many a time, you may just not get over the line in this rank, since a lot of other factors are involved in decision-making but if you believe you could make a change, you must give a honest try. There is basically no X-Factor here though some knowledge of political science would definitely help.

• Talk to your peers as how they feel and think about the present scenario and garner valuable support.
• Do organizational research. Read the policies and procedures of the organization and compare them with the competitors.
• Fix a prior appointment and have a formal agenda.
• Never ever use subjective standards.
• Support your views with research papers and authenticated articles.
• Effectively use metaphors.
• Prepare a neat presentation. Use some business buzzwords in it. Do not make it too technical. Nitty-gritty technical points can be taken up at a separate discussion.
• Always present your views with a cost-revenue analysis and show a comparative study with your competitor.

To illustrate, if you are sure that the waterfall methodology of your company is creating delay in software delivery and thereby introducing more bugs due to cramped schedules, try doing the following.

• Select a couple of completed projects.
• Collect the following information regarding the projects.
• Estimated schedules, proposed delivery, actual delivery, estimated budget and final cost
• Number of man-hours spent
• Number of changes proposed by the client and the hours required to complete them
• Bug reports and the time taken to complete them.
• Installation, maintenance and service costs.
• Prepare an alternative schedule in an another methodology (say agile). Be conservative in your approach.
• Now, estimate the hours that would have been saved by the new methodology.
• Include the additional costs that would be incurred
• Calculate the opportunity cost
• Now put these things together and create a nice presentation. Quantify everything and convert it into costs or revenue such as “the new method would lead to a 10% decrease in man-hours that would cut project costs by 7%”
• Initiate for a pilot project so that you could try the new methodology. You are running a big risk here but its worth taking.

Final remarks

A few hopeless (difficult to change) situations in my opinion:

• Cramped schedules.
• Programming thought as a linear function by the management and work allotted on the basis of pure division of labor.
• No upfront design. Starting to code straight away.
• Horses for courses policy. Hiring somebody to do the job.
• Egocentric persons with lethargic attitude.
• Right persons in the wrong jobs and wrong persons in the right job. DBA’s pushed into web interface programming and business analysts doing hands-on programming.
• No clarity in rules of procedures.
• Too much implicit communication.
• Thinking too much.

There are chances that despite your best efforts, your suggestions may not be accepted. Always try to the best of your efforts and if it fails, just adopt an another method. Remember the Pareto principle; You might spend 20% discovering bad code and 80% try correcting it. Also, communicating bad code is 20% technology and 80% psychology.

Our problems are man-made, therefore they may be solved by man. And man can be as big as he wants. No problem of human destiny is beyond human beings.

• John F. Kennedy, speech at The American University, Washington, D.C., June 10, 1963

Recommended Reading

• The Anti-patterns page at Sourcemarking
• Developer Survival Guide to know a few things other than technical
• Code Simplicity for a few ideas on how things could get complex
• A taxonomy for bad code smells by Mäntylä, M. V. and Lassenius, C
• The Bad Spotters Guide by Diomidis Spinellis
• Why People Speak Bad Code at Kilterish’s Blog
• A few Code Smells
• Design patterns in Dynamic Languages by Peter Norving

Footnotes

Welcome to the Programmers Stack Exchange community blog!

One of the great things about Stack Exchange is the way the community works. There are several ways that we try to bring our community together such as chat and Meta, as well as several community events. The next logical step was a blog, and here we are!

So what’s this blog about?

This blog is about:

• What’s happening on Programmers Stack Exchange
• Things Programmers like to talk about including: algorithms, design patterns, development methodologies, etc.
• New developments and technologies.
• And anything else that fits!

Which means there are going to be a lot of interesting things posted here. How do we know the community will like it? The community is writing it!

How did the blog begin?

The first thing we did, was bring it up in Meta. This made the community as whole aware that we were interested in getting a blog. It actually took 3 months before anybody mentioned the blog again, but this time, we had ideas. After deciding what the blog would be about, we tried to get contributors, the people that would power the blog, and write the posts. At that point, we had 8 people say that they were at least interested. So, we went on from there. We got the blog in action, writing and editing posts.

Anybody that was interested in contributing would say so in the Blog Chat Room. We gave them an account to our Trello board, and access to our WordPress dashboard. From then on, we began writing posts and had a very active system. This slept for a while, but finally came back to power. After putting everything together, we got to this point.

And then what?

Well, this is what! We launched the blog, and we are still going (at least at time of writing). If you’re reading this, I hope you read regularly, and maybe even contribute!

Where can I learn more?

About the blog:

• Stop by the blog chat room, and ping either Dynamic or World Engineer
• Take a look at our about page.