What was the biggest lesson you learned in your career as an IT professional?Reminiscing on your career as an IT professional, what was the biggest lesson you learned?
[If you can accompany your answer with an story, anecdote, link to a website, article or book it would be great thing to inspire and teach the young IT professionals!]
Never be afraid to say I don't know.
Never stop learning.
If you are running late, behind schedule or whatever with a problem that you are stuck on:
Ask for help sooner rather than later
The typical scenario is that you are coding away, something doesn't work but it seems trivial and you should be able to fix it yourself. You don't want to ask someone because that makes you look like an idiot so you frantically soldier on trying weird things, continually making the wrong choices and you end up in a total mess.
When you eventually ask for help, the first thing your helper says is " How on earth did you get into this mess?. Why didn't you simply ask someone?"
I learnt that backups are your friend.
Twice.
:(
First make it work, then make it better.
Don't try to fit all the cool features in there on the first try. Don't try to make your first version extremely fast by using a very complicated datastructure. Try not to spend too much time building in hooks you might need in 10 years.
Instead, build the simplest thing that does the job, first. Then, optimize, add features (not all at once). For each of these, follow the same rule.
Honesty is the key to any career/relationship.
I learned very early on that being brutally honest about your skills and experience was vital to my career advancement. Colleagues and management can smell doubt and fear as though it's the latest cologne.
Assumption is the mother of all screw-ups. Never, ever assume anything when it comes to circumstances in which defects are reported. Always check the obvious first, before looking for more esoteric causes.
When you hear "But I just assumed...", you know something has gone wrong.
Also, demand evidence. You need something objective (such as log files) to use for investigation. Going on user/integrator reporting is not enough. Human memories are known to be less than perfect; rely on what the machine generates.
Be careful which jobs you accept early on, you will be pigeonholed.
Manage expectations, learn to say "no".
When you're designing a system people will continually ask for more and more. If you try and please them you will go nuts. Set the expectation that they are getting X, and X only - and if the Y that they're asking for is possible then it will be considered for the next update.
Estimates are always off by at least 50% either way.
CYA (Cover Your Ass).
Make sure you can always prove later what really happened, especially if you don't trust the other parties involved. This means:
Always negotiate deadlines/deliverables.
If you get your work/life balance right, you will be happier. A happier coder is a better coder.
Don't hesitate to do overtime IF the situation requires it, but make this the exception rather than the rule. You'll find that simply discussing WHY the job can't wait until the morning makes most people realize that it actually can.
Also, once your employers see how easy it is to get some free hours off you, they might start abusing it. Don't take this unnecessary risk.
Under promise and over deliver
You don't need to take the risk of under delivering. If you over deliver on everything you do, people are always impressed. Keep this in mind when you make promises. I find it easier to negotiate the terms beforehand than making excuses or disappointments later on.
Find the balance between being realistic and being positive. It's a flaw to have the crazy "yes, we can have that enterprise app done by next week" attitude. Maybe it can be done, but again, why over promise?
Your hard drive can and will fail. It's not a matter of if, it's a matter of when.
Don't get upset when a bunch of error reports start dropping in after the software is deployed. That means that people are using it and they think it is good enough to spend time and energy to write error reports.
Programming is 50% development, 50% fixing bugs. If you're good.
I've got three main lessons rather that just one:
1. Don't give people what they ask for, give them what they need.
Very often you'll receive requests from people who are non technical asking for a particular implementation. I've often found that the implementation they are asking for doesn't really solve their problems, they just think it does based on their own misconception about the system. So always ask people what their real objective is and then try to figure out what solution would work best for them. It may sound like common sense, but I've seen way too many teams delivering what the client asked for only to find later that they've delivered a lemon because neither party had taken the time to understand what the right solution really is.
2. No matter where you are on the pecking order of a team or project, you CAN make a difference.
The pulse of a project aligns itself around the people who make things happen at all levels. So be proactive and take responsibility for making sure the project or team does the right thing, rather than just writing it off as lack of omniscience on the part of management. Things can get better.
3. It's more important to manage people's perception of the problem than it is to fix it.
I've found many times that if I provide a clear explanation of a problem or an issue and people grok the implications or consequences or even just the current status, they are almost always willing to make allowances in terms of schedule or resources. And in some cases, I've even been told that they'll live it with it and that it's not worth my time fixing it.
Never be afraid to ask for more money.
As a contractor, I would know my rate was too low in the market by the number of calls I received in the first week. I kept good records and upped the price $5/hour for all new contacts. I would also negotiate the ability to be paid for at least a 50 hour work week.
Software engineering is a very young industry.
Few points I can add towards 'the success of a s/w career'
I learned that many (if not most) software defects are the self-inflicted results of overconfident developers creating overcomplicated designs (implementing the designs poorly is common but not necessary). Nothing is more important in any field of engineering than the KISS (Keep It Simple, Stupid) principle.
When I learned to stop creating things that weren't necessary, and to stop over-engineering my code to accommodate imagined future uses that never materialized, programming became easy and fun.
There's a quickest way to add feature X, and there's the right way to add feature X.
When you're newly starting on something, the quickest way is almost never the right way.
However, if you've previously done everything the right way, you'll soon enough find that the quickest way is the right way. If you haven't, then you'll now have to add feature X in a slower and worse way!
Because of this, working on any project for a reasonable amount of time will either feel like affirmation that you are coding super god, or that you have produced a horrible abomination unto this earth.
Although you don't know it yet, there will always be another feature X to do after the current one that will further compound whichever of those feelings you now experience.
Never just do it the quickest way! By the time it starts to hurt enough to want to rewrite it properly, you'll need a fair amount of time to do it.
Marketeers make a world of difference, there are very few good ones, but those are invaluable: it is only with a great team that you can make a great product.
quotes by Mark Jason Dominus [1]:
11901 You can't just make shit up and expect the computer to know what you mean, Retardo!
11906 Look at the error message! Look at the error message!
11908 Premature optimization is the root of all evil.
11911 You wrote the same thing twice here. The cardinal rule of programming is that you never ever write the same thing twice.
11916 Always ignore the second error message unless the meaning is obvious.
1920 The error message is the Truth. The error message is God.
11963 It's easy to get the wrong answer in O(1) time.
[1] http://groups.google.com/group/comp.lang.perl.misc/msg/b2f911d6d9c5cef2?pli=1Don't take all the responsibility for a problem. Sometimes you can be furiously trying to solve a problem alone and carrying the problem on your back. Get other people involved, escalate, get other folks involved.
This may seem a bit backwards. but it can be extremely stressful when you don't get others involved and management will never know there is pain and your working at 2 AM unless you tell them.
You'll meet most of the code you write later on in a dark alley and it will be angry. Always try to write maintainable code and/or documentation. Keeping it simple helps a lot here.
I had 2 projects which I had to come back to 2,3 years after the code was written and it wasn't very fun.
Utilize user usability testing! despite all internal testing, in the end we are all developers or at least familiar with the ideas and we do not look at the application the way the average user does.
Never be satisfied with requirements from business. In fact, never be satisfied at all... until its done. Completely.
If you are working in a large corporation, you shall regard Dilbert comics strips as a 'pictorial documentary' and the book The Joy of Work (by Scott Adams) as the Bible.
Regardless of how smart are you, you can't do everything by yourself. Cooperation and 2+2=5 is the winning math.
Never trust the data. Validate your inputs.
Anecdote: I spent two weeks looking for a bug in production code. After many a debugging session, I found out that one of the 12 data files I was working on was corrupted. I had checked all the other eleven files and I had checked the start of the 12th. Sure enough the end of the file was bogus. I lost two entire weeks when I could've found it in mere hours validating the data before sending it to processing (I got lazy, there was a lot of data to process and the 11.5 first files were good).
I was "lucky", it was a numeric simulation, not something security-sensitive or anything critical.
Being right is irrelevant. Worry about getting paid.
Keep it simple principle (KISS) The most simple way of doing something is often the best, over complicating a problem often just causes large problems in the long run.
"It works on my machine" doesn't cut it. It HAS to work for them, too.
I have learnt that the calmer you are, the quicker you get the results to the problems.
These have been my big lessons so far...
1 - Learn something new every day - even the small things.
2 - Ask for help sooner rather than later.
3 - Show your code to other people - and listen to their comments.
4 - Look at other peoples code and talk to them about it.
5 - If you can't figure out a problem then take a break and come back to it in 10 or 20 minutes - makes finding a solution so much easier.
6 - Read more.
7 - Code more.
8 - Backup, backup, backup, backup. Probable the biggest lesson of them all.
There is always one more bug !
In other words, never think your environement is perfect. There is always something somewhere that will need to be fixed, improved, or changed.
Don't get trapped putting out fires. Take time to do some fire prevention.
One commercial development project I was working on got into a sad loop of quickly fixing showstoppers and releasing them only to find customers found more showstoppers. After some intense negotiations with management we put in a daily build and test system and had a 3 month feature freeze to fix items on the bug list without adding new features. It wasn't as bad as management had thought. Our distributors liked the idea and helped supply some tests for our daily build and test system.
With great power comes great responsibility.
Seriously. Stuff you run across while doing your job (like your boss's email, coworker's files, employee-private information) must not tempt you and you must not do anything that will violate your coworkers trust in you. You have root-ish powers for a reason -- don't screw it up.
It's (almost) never a bug in the compiler.
Making developers troubleshoot and fix their bugs (ok, only big production issues), regardless of time of day (i.e., usually at 3am), improves the quality of their software and changes the way they develop it.
If you are running into a problem and just cannnot find the answer, take a break, go for a walk and think of something completley different. It will help you to focus on the problem and to look at it from a different angle. Chances to find a solution are much better then.
Another very good possibility is to have a chat with your neighbour and tell him your problem. Sometimes the right idea comes into your mind just because you've talked about the problem instead of chewing over it.
Keep focus on what you intended to do. Once I created a form in a web-app where people had to enter their address. I started looking for a list of all possible cities in my country. After a while I found that such a list did not exists. Why not? I tried to find the answer to that question. It gave me insight in how names of places and cities are registered by the government......
..... And then I decided to just have a field on the form where people could enter the city of their address. I lost half a day searching for a list of cities I didn't need at all.
(I saw programmers spend weeks of time on functionality a customer never asked for.)
Obviously, this questions is highly subjective.... My story: I should have went into consulting, then self-employment 10 years sooner than I actually did! I did'nt think that I "knew enough", but after a year or so of being a contractor and then venturing out on my own, I realized that I had known everything that I needed to know already. I had good mentors and learned a lot in the 15 years prior.
The discovery of a mistake that you have made should never be covered up or brushed over. Find the correction as quickly as possible, then go confess your error and offer the solution. Work tirelessly until you have made it right.
Three things:
1) If you work in close relation with your users never implement anything unless they at least ask you twice for it.
2) Never implement new features unless you have a written request ( mail is just fine )
3) Always write down who made you change something so you can let users discuss over it instead of gettting all the blame.
I learned that it is way too easy to underestimate the time it will take to complete a project, and so it is very easy to underprice yourself too.
Lesson 1, if you made a mistake admit it as soon as possible and go to management with a plan to fix it. Mistakes you point out are far less damaging to your career than ones other people find that you caused.
Never hide the bad news (missing a deadline or can't figure out something or whatever it is, not just mistakes discussed above). Bad news doesn't get better by ignoring it.
If you have a personality conflict with someone, do not let it affect your ability to work with that person and if at all possible take steps to fix the problem. Even if I don't like someone, I never let that stop me from behaving as professionally to them as to everyone else. When the person I don't like does something right (hey law of averages says it has to happen randomly sometimes), I make sure that management hears that from me instead of only complaining. Your valid criticisms will have more impact if managment doesn't perceive you as simply disliking someone.
But don't let being polite and reasonable to the unreasonable people you get stuck working with mean that you don't protect yourself. Make sure to document problems and their resolution.
If you find that you have co-workers you feel you cannot trust, get another job as soon as humanly possible. Trust me, you don't want to stay where someone can make things look as if you did them when you didn't. If the CEO is having an affair with his secretary and promotes her to be your project manager, leave! Do not stay in no win situations and hope they will get better. They always get worse.
spend sometime learning how garbage collection works....
Never run a script you don't fully understand on a production server.
In my case it just deleted 2 databases, luckily.
If your function code doesn't fit on one page then it might be time for another funtion.
Realize that specifications are going to change. This is simply a quirk of being human in that there are those frilly elements in the UI that will likely get changed on a whim that one has to be prepared. It may be that you make a change and then have to undo the change.
Don't take it personally when your code gets thrown out. An example here is a new feature you spent 3 weeks working on and the person responsible for the project decides to cut that part as it isn't really needed and this other thing over here is, so get that done... NOW!!!! (Somehow it almost always seems like software should create itself instanteously but that rarely happens)
When commenting on an existing system/codebase that is crawling with fleas, it is not always a good idea to openly express such opinions. You may later discover that you've criticised the work of either your client (cause enough offense, you'll potentially lose the client) or colleague (offend your colleague, while creating justification for your client to ask for the flea-ridden system to be fixed at your expense). Instead, say things such as....
Well, its interesting to see that someone thought a bubble-sort algorithm would be the best solution here...
or:
If I had been involved in the solution design, I might have recommended that we do this differently.
NB: If too many of your colleagues/clients become aware that you use this strategy to soften your criticisms, the strategy becomes worse-than-void, due to the fact that when you genuinely find something interesting (as opposed to interesting), you may find people inexplicably upset with you.
you can contribute to your own downfall
Be prepared to reinvent yourself every five years.
Gathering system requirements from business folks can be very difficult, so help yourself out.
Building business software is like building a house
Iterate
Never be afraid of saying: "No, I won't fix your computer".
Don't mention any skill you don't really master in your CV.
Be humble.
Communicate to the person who is in front of you at the moment. If you don't know their level of knowledge and preferred communication style, find out and take notes.
With new technology, programming language and frameworks popping up everyday, there is no way to learn them all; so don't over extend yourself, learn what interests you. If you are interested in something, it's more likely that you will spend time on it and really use the new knowledge.
Try first Before give up, try out at least five times in different way. Take a break & try one more time. Discuss with friends/colleagues and try for last time. If nothing works, then change yourself :-)
code more!
do not overcommit!! the biggest mistake programmers make is overcommitting in terms of either features or release dates to their supervisor. always calculate a probable estimate, and then add buffers...believe me, we need a lot of them while we code.
don't be afraid to ask for help
admit your mistakes and learn from them.
Once upon a time i had "LIFE" now i have a computer
you have to trust people... but in the end, you cant really trust people
My biggest lesson was in the first year after school.
No-one gives a crap about your career except you.
No matter what the company line, policy or training system, anything the company does for you or offers to you is done for one reason - to maximize your usefulness to THEM. Now, if this matches your own career goals, then you are fine. However, if you want to move in another direction, then expect to meet resistance, sometimes very great resistance.
I have had to leave jobs simply because I was not allowed to pursue a given career path.
I was also told "don't expect ANTTHING from us" when I started working on a Master's degree. Actually, I was told that several times. They were surprised when I went and did it anyway - on my time and with my nickel. One V.P. asked me (afterward) "Why did you bother?", and my reply was "I never did it for you. I did it for ME.". I found a much better job soon after. :-)
-R
Don't be afraid to tell others if their coding is faulty. But do it carefully.
Expanding on Larry Smithmier's comments above:
Understand that, ultimately, your productivity can't be measured with static code analyses - but rather only as a function of the business value delievered in terms of either increased effectiveness (higher sales), efficiency (lower costs), or both.
Be as objective as humanly possible about the business value you deliver, but then don't be afraid to ask for compensation commensurate with that value. Because - be it salary, hourly rate, or fixed price work - if you don't ask, no one else will. It can be a real scary thing to do at first; but at some point, you simply have to step up and ask. No one 'makes it' without taking on this level of responsibility for themselves somewhere along the way regardless of the business they're in.
P.S. Also understand, the folks you'll be asking have every right to squawk a bit about such a request and prospect; in fact, if they don't squawk at least some, then you're probably leaving money on the table.
So many lessons... One that I tend to live by is "Don't take anything at face value".
What I really mean by that is that you usually need to keep digging to get to the root cause - be it a defect or a new requirement. Users may say "it's slow" and genuinely mean it, but when you finally get down to it you could end up with "this thing I do every day takes way too many keystrokes", which is a completely different problem to solve.
So keep asking the stupid questions until you understand!
Automating daily backups is best possible investment.
Take DAILY backups! Backup to multiple locations, with at least one offsite location.
There are several here that I agree with so I won't repeat them But one I learned a long time ago was:
Don't be afraid to say "It's my fault".
Take responsibility and fix the mistake - explain how you'll prevent it from happening again. Your reputation for honesty will really help sometime down the road when someone tries to blame you for something that wasn't your fault.
You can never have enough clarification and detail with project requirements.
I've worked mainly on the system administration side, having only just started out recently and my number one lesson has been "Never be afraid to make mistakes."
They happen, more often than most of us would like to admit and the key is to own up to them, learn from them and make sure you never make that particular one again.
before you roll anything out TEST TEST TEST, and make sure you have a solid back out plan.
Also, users are you friends and your enemies. Take on board what they are telling you, but never take for granted that all the things they are telling you are accurate.
The most important thing I learned was to real understand something before explaining it to someone asking for help, so you are really sure you need help. I learned it as the Teddy Bear [1] Principle. I explain:
If you can explain what you need to a
Teddy Bear
[2] you wouldn't be able to explain to anyone who may have any question about it. Usually before asking a friend's help on a function or class, try to explain to your Teddy bear(or even your
Ultraman figure
[3] or
Darth Vader egg
[4]) what you want help about. From my experience, just explaining it will make you find the solution to the problem most of the time, without bothering no one. (and avoid answering no to questions like: Did you include the stdio.h ?)
I have to give two answers because I can't decide between the philosophical answer and the technical answer.
Philosophically: Strive to learn more theory in addition to the "how to" technical stuff. As languages and tools evolve, the technical stuff will also evolve and you will constantly have to learn that anyway. But much of the theory and history will remain a solid base no matter how the languages and tools change.
Technically: Separation of UI from Code from Data Access.
Don't be nervous ever, others always thinks that you are a magician "can do anything, everything in no time, but lazy".
PFESI
Potentially Fatal Errors Successfully Ignored.
Higher up lie. Client lie. Company lie. Recruiter lie.
It's sad but what you going to do.
