276

You're not any slower in completing projects. Previously, you thought your novice projects were done when they really were not. You should sell this quality to clients. "This company might get it done faster and cheaper, but is it really done? Or will you be hunting bugs for years?" Beyond that, you need to know and accept the old idiom: "Perfect is the ...


188

Sounds like it's time for you to join the dark side: management. I'm not suggesting you give up programming and become a manager. But it seems like all the experience you've quoted up until now has been technical in nature. In simple operation of writing out a file, you can think of 10 different aspects that a less mature developer would never consider. Not ...


100

I had the (likely) same problem many years ago, it lasted for a few years and I overcame it. So maybe it would be of some interest to you to know how I achieved that, even if I'm not sure my way will also apply to you. You should also have a look here : The Seven Stages of Expertise in Software Engineering It shows that productivity is in great part a side ...


92

To become a technical lead the following are essential The ability to mentor staff members at all level of seniority, from someone who has been out of uni for 3 months to a person who has been programming for 30 years A good knowledge of your development domain. This includes: languages, frameworks, utilities, development environments A solid understanding ...


45

An important part of programming is managing and controlling complexity and for me personally, it is one of the top issues. If ignored then either the frequency of deficiencies surges or, as in your case, the ETA of finished software increases dramatically. Software complexity can be controlled and managed from many different levels and ways but a good ...


44

"Years of experience" is more of a probability scale than a measure of anything concrete. With more years in, you get an increased chance that a person has encountered things such as: Has participated in a crisis-like event. Has seen a project from beginning to end. Has seen a project fail to begin or end. Has worked on legacy code. Has worked on a blank ...


42

Reading other people's code is in fact a very good habit, since it's the best way to understand what's out there and what the programmer community will presumably be familiar with. Your code has to be understandable by you and by everyone else who will ever have to maintain it, so it's important to acquire an understanding of what is and isn't readable - ...


28

In my experience the Lead has a little bit less to do with the dirty work of hands-on programming and more to do with management. To that end I'd recommend the following Invest more time in design and architectural pursuits and development. As a lead, your function is going to centre around providing technical guidance and direction to your team. You'll be ...


27

The simple answer is: accept it. In all systems there's trade-offs to be made between reliability, robustness, security, speed, hardware cost, development cost, time to market, you name it. You will not always agree with how the customer makes those trade-offs, but you're not the one making those decisions. All you can do is provide a considered opinion. ...


21

Richard's comment is most of the answer already. Whenever you're programming for anything but a class exercise, you'll want to reuse as much existing code as possible, with just a few other considerations to balance. The advantages of code reuse are: You work faster, because some work has already been done. The existing code has a good chance of being ...


19

It sounds like your skills would be very useful for very high quality mission critical systems development, like finance/trading related applications, broadcasting, aerospace, defense... Errors in these sort of applications are very costly and they employ people who think like you as you can cover all the cases.


18

The truth is that modern systems are becoming increasingly complex. The computer is now similar to that game "Jenga" where you have all of these pieces relying on many of the others. Pull out the wrong piece and you have an error, pull out a correct/necessary piece and you still may produce an error. The more complex the system the more time you are likely ...


15

Things that Sam hasn't said that are also important: How to spec stuff up and give other developers work. Part of your job is to keep the other developers 100% utilised. Writing specs that are unambiguous is very important. How to build a skeleton/prototype application that everyone else should follow How to foster good team morale How to attend, drive and ...


15

Reading and using other peoples code is an excellent way to learn, however it can also be a trap. You don't want to turn into a Cargo Cult Programmer: http://en.wikipedia.org/wiki/Cargo_cult_programming The term cargo cult programmer may apply when an unskilled or novice computer programmer (or one inexperienced with the problem at hand) copies some ...


12

All these are by the book and good answers. Allow me to hit you by reality. Believe it or not, much of the time you will be spending in explaining managers how a problem is hard to solve or why it can not be solved in given time line or even how less important it is to solve. For this you need the skills of explaining technical things to non-technical ...


12

I recommend the following guidelines: Involve the junior developer in your design meetings and solicit his input. This will get him thinking about the big picture, even if he is not ready to do the high-level design himself. Try to isolate and clearly define a module of the application to assign to the junior developer. Describe in writing what the inputs/...


11

Your question can be handled by splitting into two sub-questions. Why use years of experience as a requirement? Because it's an easily-verifiable metric correlated positively with programming competency. Snagulus's answer already elaborates on the details of correlation, so I'll focus on the "why". The hard truth is that usually there is more than one ...


10

It sounds like you're aware of your tendency to think about everything that can go wrong. Experienced Cautious Developers often learn to follow the mantra YAGNI, you ain't gonna need it, when they try to return to a lean, agile and productive workflow after getting too choked up in the weeds of failure-mode-analysis-gone-amok. However, if you are indeed ...


8

Only thing I can see is: "You are becoming more and more valuable". As and when you get more experience you learn about things you should avoid, and this is what make you better than others. One thing you would have noticed that your code would be safer and more maintainable now. Only thing you need to do is to explain your client why it took time and how ...


8

when in doubt default to badly quoting Knuth... "Premature optimization is the root of all evil." Here is what I would suggest, as it seems like you have a problem that I have from time to time... What really works for me... Write the unit tests, as if all the code was done. document the interface. implement the interface. what you have really done: ...


8

Researchers tend to say that it takes ten years to develop a deep level of expertise. This equates to around 10,000 hours of learning the craft. How many lines of code can you type in an hour? It is probably not so much the lines of code, but what those lines of code do. The idea is that each successive target should be a bit more complex and a bit of a ...


7

I will answer this by addressing each of your questions in the post. The question is how do you know when a candidate has the required years of experience? This is normally what the interview process aims to filter out. Multiple interviews are conducted and you can normally evaluate a candidates experience against some of your own in-house developers. ...


7

Think about the practical consequences of a bug as compared to all the other problems that need solving. Consider the following consequences of creating a poorly written piece of code: Entire database gets dumped every other month. 48 hours of downtime while the backups are restored. Customer records get cross-linked. $200 worth of orders get shipped to ...


7

I think you should stick to your coding standards, but make sure you are up-front with your clients. Many clients do not know what it takes/costs to build good software. It's part of the professional developer's job to educate them. Whether you're agile or waterfall, you get some sort of agreement from the client about what they expect the application to do....


7

In "The Psychology of Computer Programming" Gerald M. Weinberg has written that programming is a form of writing. What do novelists do to become better novelists? They read a lot of books that have been written by very good writers, so that they can learn. The author is surprised by the fact that so little code is read by programmers. As was written in ...


5

The solution is to create a collection of libraries with commonly used functions which you can re-use across projects. E.g. I have a StringFunctions.dll .NET library which does stuff like encoding, encryption, decryption, regular expression evaluation, etc. This way, I don't have to continually rewrite things that don't change. Having a wrapper for file ...


5

I could now write an essay about how to do cost/benefit analysis of automation projects, but this image says more than I could ever write about this subject: source: http://xkcd.com/1205/


4

I think you need to learn to decide how much needs to be done for which project. Some project may be trivial and you really don't need to spend all that time in perfecting it. Not everything is gonna need rock-solid encryption nor everything will be scaling to million users. Writing a program which can scale well for more than a million users will take time ...


4

@Zilk, I am not great programmer and I am been programming since 1998. Even I am facing this issue now. But what I realized is ultimately quality matters. If I die today, somebody should be able to pickup what I am doing now from where I have left. Such should be the standards of programming (Universal). I have moved myself from developer to architect ...


4

Well, personal experience counterpoint. I'm rapidly approaching 40 (a few months to go) and am looking for a way out of development because ... I've just had enough. I work in a great place with interesting people, but find programming itself to be frustratingly grey, drudging and uninspiring work for me. (Other people's experience, thankfully, differs!) ...


Only top voted, non community-wiki answers of a minimum length are eligible