First, some background about my own journey into software development. When I went to college, my plan was to become a civil engineer. I took two semesters of physics and realized that the plan was not going to work. I found out that I really did not like physics, and to be an engineer you need a solid physics background. Thankfully, I did not need to decide on a major until my second year was completed, and I did some research. I had settled on Industrial Engineering, where I could take some engineering classes as well as some operations and finance classes. It sounded interesting enough, but I thought I might need some help getting a job when I graduated. So, I decided to take an introductory programming class.

This was not my first taste of programming. Like any geek my age, I had written some Basic on a TRS-80 during school. However, my first programming class was like turning on the light bulb. I quickly realized that programming was what I really wanted to do. I changed my major, eventually graduated and have had several jobs in our industry. I have now been coding professionally for over 17 years.

What does this have to do with whether you should become a software engineer? The whole story is not entirely important, but there are some points that need to be understood.

You must enjoy what you are doing. This is even more important in software engineering that some other industries. In many cases, software engineering is not a typical 9 to 5 job. It is fairly stressful as well. If you do not enjoy programming, the stress will demotivate you to the point that your code will eventually suck. I wrote what was meant to be a humorous post about the trials of the job in August 2010. It is supposed to be a joke, but in some environments those points are too true.

You can have some level of job security. In this economy, any level of job security is good. This does not mean that programmers always keep their jobs. We go through layoffs just like everyone else. However, there are a lot of available jobs and the industry continues to grow.

There is good money in software engineering. You may not see large wads of cash to start, but over time your salary will grow. If you look at salary surveys for different locations, senior level engineers can make $100,000 or more.

There is a lot of job diversity available. Do you like working with real-time devices like embedded systems? Mobile devices, like phones and tablets, are growing rapidly and there is a ton of development occurring in the mobile space. Web sites and web applications are continuously being built and require people to know UI development, some server side development and maybe even some database code. If you like to code, there are plenty of niches to explore.

What is your inspiration? Why do you code? Some people like the idea of creating something. Others like solving puzzles. You may like the fast feedback cycle in programming. If you have no inspiration for programming, you probably will not really enjoy the job.

Easier path to independence. Some people may not like the idea of being a wage-slave at some big corporation. Software development allows you to work remotely or build your own consulting business. This is easier than in many other industries, where working remotely is just not a possibility.

Obviously, there is no clear reason to become a software engineer. It is a personal choice and not some stereotype like introverted math and science lovers who are devoted Star Wars and Star Trek fanatics. To find out if you like programming, try writing some simple code. Do not try to build a significant web application or some mobile app, that is too much to start with. Look at some basic tutorials on learning a language and start coding.

Other related posts:

• 15 Tenets For The Software Engineer
• Programming Is About Keeping Basic Skills Sharp
• 7 Resume Tips For a Software Developer

Due to these issues, more sites are appearing with the hopes of “fixing” these problems. Some sites use text recommendations or endorsements, like LinkedIn, while others use slightly different approaches. The question is whether any of these new sites really improve upon the current recruitment situation. So, let’s take a look at some of these ideas.

First, we have the recent announcement from Mozilla regarding a competition:

A system proposed earlier this year by the Mozilla Foundation will be the basis of a global competition. As much as $2 million in grants from Mozilla and the MacArthur Foundation will be awarded to interested parties, in amounts ranging up to $200,000 apiece, who can propose a technical infrastructure and/or physical appearance for what Mozilla describes as a standard system of verified icons for representing individuals’ Web developmental skills.

Mozilla is trying to generate interest in a “standard system of verified icons for representing Web development skills”. There is part of this that is good, the fact that they are focusing on only web development means that there is a chance this type of initiative could work. This could be similar to the badges that the HTML5 technologies have created. The obvious problem is how do these skills get “verified” or more directly, how does a person put one of these icons on their site and how can other people be sure that this badge means something?

What about the sites that focus on this type of thing, those sites that are creating communities around skills? Here are some of the sites that I found and what they say about themselves:

• Path.to – “We love meaningful endorsements based on skills, rather than generic endorsements. We’ve engineered an endorsement algorithm to identify the most skilled people across industries.”
• Geekli.st – “Geekli.st is an achievement-based social portfolio builder where all bad-ass code monkeys around the globe can communicate, brag, build their street cred and get found. We founded Geekli.st because it was time for a united front, exclusively for developers, to build tangible credibility in the workplace.”
• Zerply – “Zerply is a professional network built around people who love what they do. We believe that professional networking can be done differently.”
• Endorse.me – “With Endorse.me, You will get your own page to create categories to place people from your social networks that you endorse in. Then you share your page for others to see. The idea came to us, because people constantly ask us for Designers, Developers, Angel Investors, or lots of other things.”
• Skillshare – “Skillshare is a community marketplace to learn anything from anyone. We believe that everyone has valuable skills and knowledge to teach and the curiosity to keep learning new things… Our platform helps make the exchange of knowledge easy, enriching, and fun.”

You will notice that I did not include any of the “business card” sites like About.me or Flavors.me as their focus is much smaller than these community skills sites. Another minor note is that Skillshare just recently added badges, similar to the Mozilla concept, and is more of a tutorial site, but I included it due to its popularity. In each of these sites, you have a way to endorse other people or even brag about your own work. The community building aspect is not entirely focused upon, as the sites all seem focused on who are the talented people with a specific technology. Can badges and endorsements fix the developer recruitment problem?

Each of these sites has there own problems. First, there is the issue of critical mass. All of these sites need much more user adoption in order to become really useful. Second, the idea of endorsements that are just “thumbs up” can easily be gamed, and even text endorsements cannot be completely believed. Third, endorsements (or plus-ones) tend to cluster around more popular people and not the people that are in the trenches, but not web-celebrities. As an example of what I mean, Joe Stump and John Resig do not need endorsements as many people know about their skills. However, there are many developers that do not get that kind of popularity because they did not create jQuery or they do not blog.

Are any of these sites better or more appropriate than LinkedIn? LinkedIn does give you the ability to search the connections for people that have actually worked with you. Ignoring that information means that you really need to build everything from the ground up. It does not make sense to try to build the network given the various networks that already exist. The endorsements are only marginally better than LinkedIn endorsements, because these sites are more developer focused.

The problem with much of the recruitment issue is that development experience really needs to be seen. Geekli.st has an interesting feature where you can “brag” about the work that you have done. I am not sure if this is what we need, but moving closer to a portfolio of work may be more useful. However, how does a server-side Java developer show their portfolio? You may be able to show an API that was created, but that does not show what your work was really like. Eventually, this problem degrades back to describing your work.

So, the real challenge is how we can use networks like LinkedIn, along with some endorsements, to understand how good a developer really is. Some of this is in a developer portfolio, but how do we “see” the infrastructure of an application? You can talk to any developer, and we all know that this needs to be fixed, but how can we fix this?

• Remember the basics. If you forget the basics of a programming language, you lose your foundational knowledge. That is never a good thing.
• Always assume the worst case. If you had formal computer science education, you learned about big-O notation. Knowing why an algorithm has no chance of performing well is a good thing. Figuring out why a particular use case seems much slower than others is how you stay successful.
• Test your code. Ensure you have tests for your code, whether you follow TDD or any other method. Depending on the type of test, you may want to target a different level of coverage, but you should still write as many tests as you can.
• Do not employ new technologies because they are new, use them because they solve a problem. As technologists, we tend to follow the hot new tools in the hope of finding a silver bullet. Utility is the key, not coolness.
• Read, a lot. If you are not reading about our industry, you will fall behind and that could have career threatening complications.
• Try new techniques and technologies, a lot. Yes, I said not to use new technologies just because they are new, but you do need to try new things in order to determine if something new is useful. Also, trying new things helps you learn and keep current in your industry.
• Fail, you will learn something. At the minimum, you will learn what does not work and you can refine your solutions. In some case, you can even consider the failure a small success.
• Ship the damn software. Sometimes you just need to get the job done, but you must be aware of technical debt. If you continuously just ship software without removing technical debt, you are well on your way to creating a nightmare when a major production issue arises.
• Do it the “right way”. Most developers have an idea of the “right way” to implement a design, but that may not always be what project management wants. This is almost a contradiction to the previous “ship the damn software” rule, but there is a balance that needs to be met.
• Leave the code better than how you found it. Instead of preaching the benefits of refactoring, think of whether you want to maintain the pile of code that keeps getting worse. If you clean it up a little each time you modify it, then it will not be a terrible mess.
• Think about concurrent access. If you are building a web application, and I don’t mean the scale of Facebook, weird issues may arise under load. Even an application with 100 concurrent users can start to see weird issues when there is concurrent reads and writes on things like HashMaps. This is just the start of the problems as well.
• Storage may be free, but I/O sucks. You may think that writing everything to disk is a great way to persist data. Generally it is, but if you use disk storage as a temporary storage area, your application could quickly grind to a slow crawl. Physical storage should be limited to that data that needs to persist for long periods of time, or when the data cannot reside in memory.
• Memory does not go as far as you may think. To start, many people will have their application and database residing on the same server. This is perfectly acceptable until both require a lot of RAM. As an example, you can easily run a Java application in Tomcat in 528MB. However, once you have to deal with scale of any sort and you add in the RAM required by the persistent storage (RDBMS, NoSQL, etc), you can quickly jump to 8GB. Obviously, this is highly dependent upon the number of users hitting the system and how much data you store in memory.
• Caching fixes everything until it crashes the server. If you are looking for ways to avoid a lot of database queries, you end up using some form of caching. The problem is that caching requires much more memory than your typical application usage, especially when dealing with data that scales with the number of users (see the previous point on memory). The worst problem with caching is that it can chew up so much memory that you run into an OutOfMemory error in java or similar errors in other languages. At that point, your server will either crash or become unresponsive and caching no longer helps because it has become part of the problem.
• Think like a consultant. As an employee, there tends to be an unwritten rule that the company can do things they would not do with consultants. Deadlines may be moved, scope may be increased, and the developer needs to find a way to meet these new constraints. As an employee, you need to use your power to state that the deadline can not move due to the amount of work required, or that scope cannot be increased without increasing the number of resources. Consultants tend to be allowed to manage a project differently than employees, and it is our job to change that.

I know there are a bunch of other ideas that keep running through my head, but this is the best list I can create for now. What other rules would you include for software engineers?

Paul Homer has an excellent post on contradictions in programming. The most important nugget from the post is:

So is programming easy or hard? When the people around you accept it as hard, then although it may take a while, it doesn’t have to be painful or a mess. But when the people around you think it is easy, they get impatient and take really bad short-cuts to avoid the necessary work, so it becomes increasingly difficult to get anything finished properly within the chaos. Thus it all depends on whether the people around you get that in order for it to be easy, they really have approach it like it is hard. Or slightly restated: it is easy right up until you fall into the trap of thinking it is easy …

Yep, programming is easy up until the point you think it is easy. The reason this happens is really a false sense of security. In the beginning, you learn about the data structures and syntax of a language. Eventually, you start learning more things like common algorithms, binary search and merge sort are good examples. Slowly, you learn more complicated things like creating and modifying a binary search tree. However, after learning these things, you eventually get a job building applications and you realize that much of what you learned is handled by frameworks. So, you start ignoring the basics of programming as you learn more about translating business requirements and technical specifications into code.

Suddenly, you start dealing with weird problems like memory constraints or memory leaks, large-scale search problems,  and data aggregation. What you don’t realize is that as you have grown in your career, your tasks have gotten more difficult but they do not seem as difficult because you have slowly gotten used to the level of difficulty. However, this is where the contradictions arise. You are dealing with a class of problems that requires you to question some of your fundamental assumptions.

In many of these types of cases, you need to revisit some of you basic knowledge. For memory issues, you need to see how many objects are being retained in memory. It could be that some of your data should be serialized to disk. For search, you may need to change your search algorithm, or you may need to build search indexes. Data aggregation, which has become very important with all of the social data that is available, requires you to revisit how you are storing data and how you are querying that data.

Retaining your basic skills is something our industry tends to forget because of the wide adoption of various frameworks. Are sites like Programming Praxis, which help you practice programming, really useful? In some cases, they absolutely are. Forgetting how to create a binary search tree is not catastrophic, but remembering that these basic data structures and algorithms are critical to your career. The only time that you can really ignore some of these foundations is when your career is focused on creating administrative applications, like form based data entry, with a limited number of concurrent users. There is a large segment of the programming population that does this type of work, but there are a lot of programmers that create all sorts of interesting applications.

There are some people that believe you need to be working on side projects, meaning applications that you are building outside of your current employment, in order to be a good hiring candidate. I am not a fan of this opinion, but I do value the idea of side projects. Typically, people will work on side projects that have only a limited relationship to what they do at work. The benefit is that these side projects will broaden their skill set because they are dealing with different types of problems than they normally see. I find side projects to be better than programming exercises because they have meaning to the person doing the work. Would you rather write another binary search or create an application that you and others may find useful? Obviously, I prefer side projects for this type of work. These side projects are also a useful way to learn new technologies and languages if you are not learning about them at work.

How are you keeping your skills sharp?

The team seemed very concerned about achieving a high velocity. They showed reluctance to slow down and spend more time in “grooming” and planning. Previously, in an effort to optimize velocity and reach “hyper-productivity” the team had capped the amount of time the product owner could use for grooming at 5% of the sprint. However, I was starting to think that really wasn’t enough time. It was forcing a lot of important design decisions off onto myself and the UX designer without getting the opportunity to explore different options and get feedback from the development team. There may be situations where this setup works well, however I have a very smart and talented development team and I felt that spending more time grooming and brainstorming potential solutions to the problems on the backlog with the team prior to designing the solution would, in the end, result in a much better product.

Basically, the development team was so focused on the amount of work to be completed in a specified amount of time that they forgot the goal of producing a better product. This type of stress normally comes from the project manager, they were worried about the calendar. When did developers start worrying about the calendar?

Part of the problem is that developers are required to estimate project tasks. In traditional or waterfall projects, these estimates are given in hours or days. With agile methods, developers are often asked to only provide a relative difficulty of the task. For relative difficulty, I have seen various measures like points (based on the fibonacci sequence), t-shirt sizes (S, M, L, XL), donuts, beans and many others. The problem with relative measures is that they do not relate to the calendar directly. In the end, most clients want to know when a selected feature set will be complete, and sometimes there are other calendar pressures like launching before a conference or staying aligned with some business cycle (like monthly accounting). Why is agile used in these scenarios? Because agile methods are related to getting a working product. You implement a feature during a sprint, instead of various people working on tasks that are not entirely related to each other except due to related due dates.

Another problem with estimates is that they are typically not related to the developer doing the work. One way that this issue has been avoided is to have the developer scheduled to do the work, to estimate the task. However, we all know that schedules and reality do not always see eye to eye, so you may have a developer working on tasks that they did not estimate. Invariably, there are differences in the actual hours needed to complete the task and the original estimate. Some of this is due to the estimate-developer mismatch, but sometimes it is just a matter of expectations. In most projects, developers are allocated as 100% utilization for the project. In reality, this is almost never true. During a week, the developer will at least have project status meetings or scrums. In many agile methods, a daily 15 minute scrum is required, which means that the developer already loses 1.25 hours for the week. If you add in the time to process emails, about 30 minutes per day, you have lost 3.75 hours or almost 10% of your week. This does not include any other types of distractions, and the best you can expect is 90% utilization from the team members.

So, we already have the fact that estimates are likely flawed, the project plan is possibly flawed due to lower than expected utilization, and the potential for a business driven deadline, all pulling for attention when looking at the project schedule. Agile methods have attempted to remove the first two issues, by using relative difficulty as the estimate, but that often gets translated to effort hours in the long term in order to determine an approximate date when the project will be complete. Obviously, we could talk this problem in circles, because without data, there is no proof of what could happen or at least data showing trends of what has happened.

In agile methods, the concept of velocity has tried to make use of the trend of previous sprints’ work completed. However, this trend tends to become a target instead of just a trend based on data. Developers try to increase their velocity, because it makes them feel productive, and management likes to see the velocity remain stable or even increase over the life of a project. This is the problem with data, it makes people feel like they can make decisions about the project, while they are forgetting about the main goal of developing a solid, functional product.

What if the only metric that was measured was total points delivered? Or we measure points delivered as a percentage of the required points for the minimum viable product? This is what we really want to know. Is the product done? If not, how much work needs to be done until the product is minimally ready for launch?

In a day and time where people are often tied down by 10+ tasks and to-dos a day, it can be hard to keep up with it all. I find it hard to believe that any true freelancer, professional or student can live without some type of GTD (getting things done) tool; it’s just a must-have for staying organized and remembering what needs to be done for the day, week, and month.

With that being said, this list of 13 GTD tools will help you get organized on any platform – whether you’re on Windows, Mac, Linux, a mobile device or right on the web. From managing tasks to creating goals to organizing a project, this list has got you covered and at a company I work for that developed a live chat customer support software we tried almost all of them internally. So here you go:

Things

A stunning task manager with powerful features and synchronization between devices. You can view all to-do items for the current day, the next day, and future days. You can also organize/group to-dos into projects and areas of responsibility. You can even delegate to-dos to your coworkers and teammates; so it is also great for working with groups.

Available for Mac, iPhone/iPod Touch and iPad.

Todoist

Todoist is an online task manager with a very simple interface and built-in calendar. You can organize your tasks into projects and even sub-projects and sub-tasks. It also includes reminders, Gmail integration, Outlook integration, plus a Chrome extension and Firefox addon.

Available for Mac and online use.

Chandler

“A notebook you can organize, back up and share.” You can separate your to-dos into now, later, and done sections so you know what’s more important and what is already completed. You can also organize your items into collections (via drag and drop) and add stars to important notes and events.

Available for Windows, Mac, and Linux.

Beeswax

“An information management system inspired by Lotus Agenda” and only for the true geeks at heart. The UI is text based and formats your tasks in an outline-type format (similar to Microsoft Word). It is very basic, yet has quite a few keyboard shortcuts (command key binding). Tasks can be organized into categories and sub-categories.

Available for Linux.

Nozbe

This is a web-based time management and project management application that is geared toward small teams. Tasks and notes can be organized into projects and you can star the ones that are the most important. You can also attach files to your notes and tasks. Nozbe even integrates with many useful apps including: Evernote, Twitter, Google Calendar, Gmail, Yahoo, and more.

Available for iPhone/iPod Touch, iPad, and online use.

ThinkingRock

A Java based application that is great for collecting thoughts, creating to-do lists, organizing tasks into projects and sub-projects, and creating “Do ASAP” actions (for those really important tasks). You can also use it to create goals, which can then be put into a “someday” or “maybe” category.

Available for Windows, Mac, Linux, iPhone, and Android.

Toodledo

Toodledo is a very popular and powerful online to-do list organizer. Your tasks can be prioritized and organized into folders and sub-tasks. You can also create notes and goals. Toodledo has numerous integrations and other features like email, SMS reminders, IM support, a Google Gadget, Twitter support, a Firefox addon, Apple dashboard widget and more.

Available for iPhone and online use.

Remember the Milk

Remember the Milk (also known as RTM) is a popular favorite for managing tasks and creating to-do lists. It is very simple, yet offers superb functionality and integrations with Gmail, Google Calendar, Twitter and more. You can also get reminders via email, SMS or IM and share you tasks with others. There are few other great to-do list apps on the web but RTM are probably the most popular one.

Available for iPhone, iPad, Android, and online use.

MyLifeOrganized

With MyLifeOrganized you can collaborate and create tasks, sub-tasks, projects, goals and even mind-maps. The interface is customizable and actually designed to run from a portable drive. One of the most unique features is the ability to enter the amount of time required for a task. You can then ask MyLifeOrganized “I have only 30 minutes now. What is the best thing I can complete from my To-Do list?” and it will let you know which items you can do.

Available for Windows, iPhone, and Android.

Doit.im

Another simple, yet stylish to-do list manager that works on just about every platform and browser. You can organize your tasks into projects and share with others. There is also a quick-add feature, which is great if you’re in a hurry. The different view modes lets you you filter your tasks by time, context, project, contact, calendar and archiver.

Available for Windows, Linux, iPhone, iPad, Android, and online use.

TimeGT

“TimeGT is a powerful life and task management software that keeps data in sync using a secure server and freeware desktop clients.” Tasks can be tagged and organized into nested projects with unlimited depth levels. You can also separate the items that you can do now from the ones that you want to do later or someday. TimeGT also offers secure synchronization and backup so that you never lose your data.

Available for Windows, Mac, Linux, and online use.

Veetosoft

Veetosoft offers 2 different programs: uTodo (“simple and fast to-do list software”) and uOrganized (“powerful task list software”). uTodo lets you tag your tasks and organize them into lists, while uOrganized lets you tag your tasks and organize them into folders. Both offer task filtering, organization via drag and drop, keyboard shortcuts, sticky notes, themes, and the ability to run the program from a portable drive.

Available for Windows.

Wunderlist

Wunderlist is very similar to Doit.im; it’s a beautifully designed task manager that is accessible from almost any device. Items can be started to show importance, organized into lists, and shared with others. You can also customize your background with 1 of 12 built-in designs. Tasks can be filtered and viewed by due date, importance, or according to whether or not it has been completed.

Available for Windows, Mac, iPhone, iPad, Android, and online use.

What have we missed? What’s your favorite GTD tool?

This post was written by Lior Levin who works for iAdvize and is also a marketing advisor to a psd to html service company that works with designers from all over the US and Europe.

I started thinking about this recently for a few reasons. First, Chris Brogan wrote about talking in a customer’s language:

Would you give that same kind of opportunity to connect if it were your customer? Do you talk in their language, on their device of choice and about the topics that interest them?

There are two important things to note in that quote. First, are you talking in their language? Do you use their terminology? Do you try to make technical issues sound understandable? The second point is which communication medium does your customer prefer to use? These ideas are very important for any software engineer above the most junior levels of experience.

Speak Their Language

When you are talking with a customer, you need to speak in different terms than you would with other software engineers. This should be obvious to most people, but it is not an easy skill to master. First, when do you give the users technical detail and when do you give them a summary of the situation? For example, if you have a data issue that needs to be fixed, do you tell the users the details of the issue? Or do you explain the problem in terms of how the application reacts? So, your data issue may cause an error in the application, and that is what the users understand.

The communication also needs to use the same terminology as your users. In blogging software, most of the textual content is described as posts. However, your users may describe things in terms of articles. This may not seem like a big difference, but hours of discussion could be lost due to such terminology differences. It may even be helpful to create a glossary of terms when developing any documentation, that way the terminology is documented for when new people join the team.

Use Their Tools

The second question about which communication tools to use is just as important as the terminology. It may seem like a small thing, but if a company typically uses conference calls to meet and make decisions, then an email will probably not convey the same level of importance. In some companies, the opposite is true and email is the main communication medium.

The choice is not as simple as phone or email either, and it changes with each department. Your fellow programmers probably communicate using instant messaging. When you are dealing with QA, you probably will communicate using your task/issue tracking software like JIRA, Bugzilla or TRAC. In some cases, the communication medium could even be a status report sent to your manager. Each group typically will require a different method of communication.

As a software engineer, you may not think that all of this is important to your job. However, only the most junior developers do not need these types of communication tips. As your career progresses, communication can become as important as your coding skills. Developing a breadth of business skills in addition to a breadth of technology skills is very important to your development even if you do not want to be in management. If you are thinking of going the entrepreneurial route, these skills are even more important than if you stayed in a large corporation.

the really important thing to remember, as a reader, is that there is no objectivity in journalism. The guys that say they’re objective are just pretending. Everyone is conflicted in different ways, and yet the “rules of journalism” don’t require any sort of transparency or disclosure unless it’s a direct financial conflict.

Everyone has some bias.

I am sure you are wondering where this is going, since I have not commented about the blogosphere problems in quite some time. As a software engineer, if you remember the “everyone has some bias” mantra, you can actually change your career. The key is to remember that “everyone” includes you. As an example, I have been developing in Java for over 10 years, so my experience affects my bias against other technologies. I will likely get some complaints about this, but I do not like using PHP as a final implementation for a web application, mainly because I do not feel like trying to scale PHP. Java has its own issues, but scaling Java is a known problem and only requires a little research. I know there are companies using PHP with huge scale, like Facebook and Yahoo, but there are a lot of companies that cannot hire the best and brightest engineers to solve their scalability problems.

How does this anti-PHP stance help me? When people ask me what language to use, I can start by saying I am a Java developer, so my opinion is biased. I can explain my issues with PHP and tell them to search for some information on scaling PHP on the internet if they choose that language. PHP is great for prototyping a web application, and may be an acceptable choice for most applications if you are not planning to scale to the size of Facebook.

By acknowledging my bias, and ensuring that I include it in analysis means that I can provide a more complete picture. If you are a consultant, this becomes very important. If you have biases but do not include them in your analysis, you are not being honest with your clients. That is not a path to success.

Experience Is Bias

The problem that most people have is that they see their experience as a valuable tool, which it is, but they use it as a hammer and everything is a nail. Everyone is guilty of this at some point. Recognizing experience as only a tool is important in avoiding unnecessary bias. Experience also needs to retain its context in order to be truly useful. If you have a performance problem in your code, experience may tell you to look at the database queries and you may focus on that. A quick check to ensure the database is not obviously a problem is good, but you can’t focus on anything until real performance profiling is completed. The current application may not be similar to your previous experience, so your bias is actually getting in the way of solving the problem. Granted, it is very difficult to see when to rely on experience and when not to. This is one of the things that separates really successful people from other people that want to be successful.

So, admit your bias and recognize your experience as additional bias. You and your work will benefit from it.