10 Things I Wish I Knew as a Web Programmer 10 Years Ago

Chris Roane PHP Tips and Tricks,

When I reflect on my past experience as a web programmer, there are many things that I know now that I didn’t know ten years ago. The learning process was valuable, but I could have been at a different spot today as a PHP web programmer if I knew these things earlier. Sometimes you don’t have the info when it would benefit you the most, but my hope is that this list will give you something to reflect on.

These items are not listed in order of importance. They are all valuable and I would suggest reflecting on your own career (even if you are not a web programmer, with some of them).

#1. Over Estimate Your Time

Unless you are 100% confident in what you are programming, you should always over estimate how long you think it is going to take you to complete a project or a task. This will give you more cushion room, but it will also make your time more valuable because you get projects done faster than your estimate.

Refuse to estimate on anything that you cannot get at least 50-75% comfortable with (in other words, you should have a good idea on what you are estimating on). If they will not give you the required time to look into it and make a more educated guess, and they force you to create a rough estimate, I would calculate what you think the worst case scenario would be, and times that by 1.5. This may not make upper management happy, but it does show your level of comfort with certain systems and this method is a safe approach to the unknown.

The flip side to this is that if you estimate a project and it takes you longer, this does not make you look good, and I suggest avoiding this as much as possible. As you gain experience with different systems and with the programming languages you work with, you should get a better idea in how long things take. If you get really good at this, you will always end up getting projects completed faster than estimated.

#2. Get Familiar with a Framework System

A framework system, such as CodeIgniter, will increase your productivity if you use it properly.

If you are working for a company that does not let you use a system like this, and doesn’t have their own framework, you should learn at least one anyway. These type of things are great for your resume and can get you jobs. I suggest spending some time researching which php framework you want to go with and then tackle it full force.

I would also suggest getting experience with WordPress, Drupal and/or Joomla.

#3. Don’t Assume that Where You are Working is the Best Opportunity

Will the company you work for be able to pay you what you want to make? What about in 5 years? Is the company growing and going anywhere? Are the people you work for happy? Are you constantly over worked? Do you feel under paid?

I’m not suggesting that you constantly apply for jobs. But it is healthy to have a good feeling for what else is out there. Talk to other programmers in your field that live in different areas (or the same area) and see how much they make. Get familiar with different companies where you live and possibly other companies elsewhere that would let you work out of your home office (like my current situation). If you open up your job market outside of your current city/state, there is a good chance you can increase your salary range greatly and have the opportunity to work for more progressive companies.

The point here is that if you want to see your career get progressively better, you should always be open to other opportunities. Don’t let your current employer make you feel guilty for going with this approach. Sometimes the best option is to quit working for your current employer and join a different team. Just make sure to keep your options open and don’t burn bridges.

#4. Don’t Get too Comfortable with GUI Systems

I learned PHP and how to work with MySQL by using systems such as phpMyAdmin and editors such as Dreamweaver and Eclipse. However, this is not something you want to box yourself into.

Don’t get me wrong, I love to use GUI programs when it makes sense to, but there are some web companies that don’t let you use GUI systems on your own computer. For example….you may need to edit a file or work with MySQL using the command prompt (SSH). You shouldn’t necessarily need to know how to be a server admin when your focus is on programming, but these are things to be aware of and prepared for.

And again, having this skill listed on your resume is a huge plus.

#5. Learn How to Use and Work with SVN

This is similar to #4, but is more specific to a program installed on a lot of servers. This has become a standard in most companies, and I suggest you start using it if you haven’t already. Overwriting a file or making an incorrect change is not a huge deal when using a source control system like SVN, because you can revert back to previous versions easily.

This also helps if you are managing other employees because you can see exactly what they changed in the code, and when it was changed. Over the last 5 years or so this has become a requirement for most of the top web companies, and it is something you will want to learn how to work with.

#6. Maintain a Website or Blog

This may seem obvious, but when you are “comfortable” in a job, you may forget the value in doing this. Having a maintained website is great to have if you were ever to lose your job (it adds value to your resume and skill set).

Also, it makes sense for us who know how to build and work with websites to have one of our own. Having the writing skills and the how-to in making a website profitable will make you standout over other programmers.

You can create a blog of your own or even help with the development of an ecommerce web design.

You will also learn other tools and systems with this valuable experience.

#7. Master Organization

Being unorganized will cause many problems. You will forget about meetings, issues with websites or other things that will make you look bad. If you take this seriously and create systems that keep you on track with what is important, this will make you look like a super hero.

In fact, this is an area that most programmers are not very good at. They may be very intelligent and can write awesome code, but when it comes to being reliable and dependable, they fall flat. This is your opportunity to shine!

#8. Learn Outside of Work

Often times we get so busy with what we need to get done throughout the work day that we do not have the time to learn anything new. Or maybe you work at a company that doesn’t give you time for learning new technologies. In any case, you should be spending some quality time outside of work either learning new systems, languages, techniques or just fine tuning what you know by working on your own website.

If you don’t do this, you run the risk of being outdated with what everyone else is using. This isn’t to say that you can never catch up, but this is not a place you want to be if you find yourself out of a job.

Some great questions you can ask yourself:

  • What could I learn in my field that would make me more valuable?
  • Are there any projects I did not get because I didn’t know a specific system or framework?
  • If I was to get fired today, what would be the most valuable thing to learn that could be added to my resume?
  • What do some programmers who make more than me know that I do not know?

#9. Learn How to Waste Less Time

Along with #7, this can be used in any field. Unless you have no work to do, you should not be checking personal email, facebook, twitter, etc… during work hours unless it is work related. On top of that, you want to be constantly thinking about how you can get more done in less time by implementing different coding techniques or improving the code you use (also see #2 above).

#10. Learn from and Own Your Mistakes

If you broke something, don’t blame someone else (even if you are only partially to blame). Own up to what you are responsible for with the mistake. This shows a level of maturity, but don’t think that it ends there. Go out of your way to make sure that you do not make the same mistake again.

As a manager in the past, this is what got under my skin with programmers on my team. They would end up making the same mistakes over and over again. If you don’t learn from your mistakes, you will look incompetent. If this is something that you spend a lot of time practicing, you will end up getting promotions and raises because this matters to employees and supervisors. And it guarantees that you will get better as time goes on.

Save more time and in website design by getting these 20 really useful cheatsheets for free.

There is always room for improvement, regardless on where you are at in life. Don’t lose sight of this.

 

Do you agree or disagree with this list? Is there anything you would like to share that you’ve learned through experience?

Photo taken by Elise McLaughlin

34 thoughts on “10 Things I Wish I Knew as a Web Programmer 10 Years Ago”

  1. 10 Things I Wish I New as a Web Programmer 10 Years Ago…

    When I reflect on my past experience as a web programmer, there are many things that I know now that I didn’t know ten years ago. The learning process was valuable, but I could have been at a different spot today as a PHP web programmer if I knew these…

    Like

  3. 10 Things I Wish I New as a Web Programmer 10 Years Ago…

    When I reflect on my past experience as a web programmer, there are many things that I know now that I didn’t know ten years ago. The learning process was valuable, but I could have been at a different spot today as a PHP web programmer if I knew these…

    Like

  5. Very true. Being a PHP guy myself for over 6 yrs, cannot agree more. Some more things which I feel need to be there –

    11. Learning Design Patterns – it feels so alien when you stand among (lets say Java) devs discussing GOF.

    12. Certifications – primarily Zend, Enterprise Architect & WS certifications will help in long way.

    Like

    • I agree on your tips…even though I don’t have any certifications myself. That is one of those things I have been wanting to do for a long time, but never made the time to pursue it.

      Learning design patterns is also valuable, because it will help you code much better overall. And if you do MVC right, your designers will like it too.

      Thanks for input!

      Like

    • I actually don’t use Notepad++ as my primary programming editor. More recently I have been using Aptana, which I’ve grown to love.

      I do appreciate you pointing out the spelling issue. I can’t believe I missed that. You are not being a Nazi for bringing it up. 🙂

      Like

  7. Thanks for pointing out the spelling issue Bjorn and ESN. I can’t believe I missed that one. It is now fixed.

    I spend so much time working on the grammar/spelling of the articles, that sometimes I forget about the title.

    Like

  9. Great little article, I added my own feelings / additions.

    #1. You will be asked to make estimates on things you can’t possibly. My advise is simple… make it non-binding, and given them a score on how confident you are… “It should take about 15 weeks, and I have 1% confidence in that estimate” — The more time they give you to estimate, the higher your confidence level can be.

    #2. Try out different “styles” of frameworks, Django/Rails, Drupal/Wordpress, Wicket… touching a lot of different styles will expand your comfort zone a lot.

    #3. Constantly apply for jobs! If you really want to work at Google, keep applying.

    #4. Don’t get UNcomfortable with GUI systems, it can run to both extremes. Being able to do everything from a console and vim instance is great, but realize you might also be expected to work from VS.net or Eclipse, they have their own learning curves. Just like touching frameworks, touch different GUIs as well.

    #5. Learn SVN, but also learn a DVCS (as they are absolutely the next generation). You can learn both at the same time by using a tool like git-svn (lets you talk to SVN via Git). SVN is a great tool, but DVCS are were we will be in 5 years.

    #6. I would argue having a personal website is … somewhat useful, in some cases. If you want to have something really useful, work on open-source projects, you will network, meet people and have a proven project that is more challenging that a personal website.

    #7. Organization is useful, as long as you realize no amount of organization can help you deal with being over-subscribed. Keep it as simple as possible.

    #8. Trying to pick an outside of work project/thing to learn that is useful is great, and if you can swing it go for it. But, I would argue you do something after work that you can get “into”, open-source project, something you feel passionate about — so you will really get involved and work on it.

    #9. I agree, wasting all day on twitter probably isn’t good — but I think the best way to “not waste time” is to constantly revisit the tools you are using. A dull knife will slow you down as the saying goes.

    #10. I really think this one, is probably the single most important point. Own you mistakes, and ADMIT them. It is really important to your integrity as a developer that you own up to mistakes not just privately, but to the team / other developers so they can learn from them as well.

    ++11. Rahul in the comments brought up design patterns, I Couldn’t agree more, learn them, love them, use them.

    ++12. Certifications are generally speaking, IMHO, not very well respected outside the HR department.

    Like

    • Robert,

      Great comment! I agree with most of what you said, and there is a lot of great info here.

      – #1. This is the only one where I have to disagree with you. For this example, let’s say the owner of a company asks me for a rough estimate and I give them X hours as a number and I tell them that I am about 5% confident with that time frame. They go forward with the project with your estimate and it ends up taking 5 times as long you estimate.

      In most cases the owner in this scenario will be upset with your estimate. This has happened to me in the past and it is something that should be avoided.

      If you aren’t confident with a project/task, this should be reflected in how long you think it will take you to get it figured out if the project goes through. I’ve implemented this technique in all of the web companies I have worked at and I have been very successful with it. Now with that said, this is not what I would send directly to the customer.

      – I really like your #5 and #6.

      – #7. That is a great addition. Part of being organized is making sure you aren’t too busy and trying to simplify what you can. This is very similar to what you said on #9.

      – #12. I do agree with you that they are more for show than anything else, but it seems that some companies put a high value on some certifications.

      Like

      • Regarding #1. In my experience, padding is common, but almost always wrong. You are making a decision for someone else in effect, based on how much risk you think that THEY should be taking… it isn’t up to you. But let me break it out by environment.

        ——————–

        Employment: You boss comes to you asking you how long feature X will take… you think about it and realize you have NO idea. Options at this point are:

        ~ Pad it like crazy, you will probably not MISS the deadline, but you look silly if other programmer gives an estimate 1/6th yours, and hits it. Basically, you assumed the worst in your estimate, without actual knowledge. This can still make you look horrible.

        ~ Refuse to give an answer, become “that guy” the non-useful unhelpful guy.

        ~ Be an optimist, underestimate and miss the deadline.

        ~ Be honest, tell him you have no real idea, based on your minor knowledge of the system, you suspect, with about 5% confidence that it will take about a week. He might say “that is fine, start on it, and update me” or alternatively, “What will it take you to get to 50% confidence”, either way, you are allowing the person who has to deal with the results upstream be involved.

        … I obviously think the last option is the best.

        ————————

        Consulting: Client calls you are asks for a quote on feature X, you have no idea how long it will really take.

        ~ You pad the estimate, and most likely loose the client. Non-starter for the consultant who uses contracts to feed his family.

        ~ You tell the client you can’t possibly help him without more info, and this leads to the same outcome as the last point. You are “that guy” the guy who can’t work without more info than anyone has…

        ~ Be an optimist, and miss your deadline. If you were silly enough to enter into an FFP (Firm Fixed Price) agreement, you loose money, client gets late work, everyone is bitter. If you are on T&M (Time and Materials) client is bitter cause they felt you lied to them because you were not clear about the level of risk, maybe loose a client (and reputation).

        ~ Be honest, tell them you really don’t have any idea how long this will take, but you are willing to start working via T&M and you will see how it goes, they can pull out at any time, and everyone is in the loop and understands the risk (lack of confidence) at any given time… they can ask you to start working on improving the estimate or just start working on the product it is up to them, and they are in charge of the amount of risk.

        ———————

        My point is, you write the software to fit your clients, or your bosses risk threshold… let them make the call on the amount of risk the project can handles, and when you are the client (or project manager / bidder), you hope that your programmers don’t lie to you, so you can make that call well… and understand, padding estimates hugely is a form of lying, and even fraud on government contracts if it is big enough.

        Like

      • I think there was some confusion. Based on your description above, and after re-reading what I wrote, it sounds like it is assumed that the supervisor/boss does not know about the techniques that I use to come up with estimates. I’m not inferring that I lie in anyway. My main concern is that I accurately communicate how long it could take me, based on my knowledge and my experience.

        The illustration that I used in the article was for the absolute extreme scenario…which probably would be with a programming language you have never used before (which I have been in that scenario). For most scenarios I am usually able to get pretty close to the 75%-90% sureness, and so I am not giving crazy time estimate.

        Below is an illustration for how this has worked for me. And keep in mind, often times I would explain my thoughts to the company owner while doing all of this…

        Boss says: We need a quote for this project.

        Chris says: Based on previous projects I’ve done in the past, I think I can get it done within 4 hours. However, there have been scenarios where it took 7 or 8 hours (with the worst case scenarios I’ve had experience with). I would probably give myself 6 hours to account for the unknown factors.

        Boss says: Given that information, I am going to charge the client for 6 hours (unless we can nail down the spec further…sometimes it would be more or less, depending on the value of the code I am working on) and we will eat any time over that (assuming it is included in the spec).

        Going this route allows me to hit my lower estimate about 90% of the time, and the client gets a fair price for the work and is happy because we deliver the project on time and on budget.

        I would not have this same conversation with the client, and I agree…you need to stay competitive and honest with the client. I find that clear communication and creating a detailed specification that outlines as many details as possible, works out the best for everyone.

        I do think we are on the same page here, with little differences in terminology. I just have a hard time with the idea that my boss/supervisor is going to understand what it means when I tell him I am only 5% sure on my time estimate.

        This is very valuable and I appreciate you sharing your thoughts on this! I think there is a lot I can learn from what you shared and you sound like someone who has more experience than me.

        Like

  11. I think it is rude to ask people how much they make. If they bring it up in a conversation, fine. Networking with people is fine. Salary information without personal identification is widely available on the web. And anyways, companies often pay a little more than you made before, usually they have a range based on the widely available information. They hire based on their perception of specific skills they need, which is often quite skewed from reality anyways.

    Accept that you will make the same mistakes over and over, just make it so you can recover so fast that that in itself amazes people. Learn good habits with your favorite tools, and realize what backups and revision control is for.

    And always allow people to adjust text v. background colors and text size. You don’t know what is wrong with their eyes and what device they are using. Jeez, even the crappiest windows apps figured that out decades ago.

    Like

    • Joel,

      Thanks for sharing!

      – I do agree that you should not be going around asking people what they make. You definitely want to make sure you know the person before you ask them an intimate question. There are ways you can be tactful and get the general information you need…such as: can you give me a rough range around what you make at [XX] company?

      The general idea is that if you are being paid 1/2 of what most people in your industry make, it might be time to switch companies.

      – Why would you make the same mistakes over again? Isn’t this a sign that you aren’t learning from your mistake? If I am a manager, it is unacceptable for a team member to keep on making the same mistakes.

      – Interesting input on allowing people to change the text and color. I’m not sure many designers would agree with you on this one, as most websites are designed to use a certain color scheme. 🙂

      And again, I appreciate your input.

      Like

  12. As I’m just starting out with freelance web design, (and have only had one client >_>) I’m still learning how long it takes me to do things. But concerning #9, I do find myself checking facebook “real quick” when I’m at a creative road block. An hour later, I wish I’d stayed more focused.

    Like

    • Yeah, FB and Twitter can be a drain on time. What I have been trying lately is to only check my FB profile once per day or every other day and that helps a lot.

      Thanks for sharing.

      Like

  16. Thanks for this post Chris, I am a graduate in my first Web Applications Development job and this kind of ‘down the line’ information is incredibly handy to me.

    Keep up the great work, and PS, nice site design!

    Like

  24. wow i was amazed on this tips it’s very helpful god thanks . i’ve been a developer for 1 years + and your advice is best for me to take on..
    thanks

    Like

  25. it’s very great article and I enjoyed. I read it times and times and I’ll do all of the numbers. thanks a lot.

    Like

  26. I’m trying to learn CodeIgniter but I found it very difficult ! I think it’s even more difficult than learning a new language !! how can I learn it ? is it’s own tutorials enough for learning it ??? please help me !!!

    Like

Comments are closed.