It's said that one of the best ways to grow is to learn from one's own mistakes and those of others.
In fact, there are some organizations that find zero-based thinking so important that they actually catalogue all of their lessons learned such that they don't make the same mistakes again.
With that in mind, if you could go back in time and change just one technically-related decision that you made at some point in your career, what would it be and why?
Mine would have to be have learning BASIC as my first programming language. That screwed me up for a while. I'm not saying it's a bad language per se; it just doesn't encourage good programming practices to new programmers.
I wonder if anyone is like me in this and can't think of anything at all. Everything that happened the way it did made me who I am today, and I'm cool with how things are. If you never make the mistake you can never learn from it. While this might seem like a bogus answer at first, think about it again.
Database Triggers are generally a bad idea.
When you first learn about them and start using them, they seem like a magic bullet. But then, 6 months down the track, you've forgotten what triggers are there and what they do. DML becomes magic, a single insert has completely unexpected results.
Avoid triggers if you can If you must use them, try not to have any business logic in them. If you must have business logic in them, make sure they are documented well.
As a kid, when I got a new PC, I started playing around with programming, and thought pretty good about that. However, I soon replaced the time I was spending on programming by time I was spending playing games.
Well, if i could change that, I would have spent even more time programming.
My change would be learning to be language agnostic a lot earlier and accepting that different languages have different strengths and weaknesses. Would have saved me from a few years of championing through making all sorts of weird stuff in C/C++ that should have never been done in those languages in the first place.
It also thoroughly expanded my view on programming and made me a better programmer in general.
Waiting too long before learning more languages. I went a stretch of several years where I only used one.
Many years ago when memory was very expensive and we cared about such things as CPU cycles, I spent an awful lot of time optimizing a signal processing routine to squeeze every wasted bit and optional CPU cycle out of it. I hate to admit exactly how much time I spent on this, so I won't! (But in those days this was not an unusual practice.)
Why do I regret this? Right after we released the product, Intel released the 286 processor and suddenly my careful optimizations weren't so important. I regret not keeping up with the technology. I was a young developer then and did not understand the scope of a software engineering job. Ever since then, I try to be very cautious about how much time I spend optimizing code beyond the usual best practices. I also keep my eyes and ears open to be aware of what's on the horizon in new technology that might affect my work.
During beginning of my career I searched for a company with vacancy of junior with my skills. If I could change that, I would not stick to my skills, instead I would select a company and learn all they required.
I would have written more complete specs so my customers and coworks all knew the score before anyone started building.
You may not agree with what I am about to say as I am sure people will fall on all sides of my comment:
I can't necessarily think of a technical decision that I would take-back. That said, I wish I could take back all the times I got too wrapped up in technical minutiae or pipe-dreams of the ultimate technical solution and failed to keep focused on the business problem I was tasked to solve.
I am not admitting complete failure to solve my businesses' problem but when you are amongst the technical team discussing potential solutions to the business requirements it can be so easy to branch out tangentially on all sorts of hair-brained ideas and not zooming back into simply meeting the requirements.
Face it, most general business solutions are pretty straight-forward designs (I am generalizing!) and don't need a new operating system or message queuing infrastructure to meet the requirements.
I love geeking out as much as the guy, but if I could take back some possibly over-engineered solutions to some fairly simple problems, that is what I would take back.
I used to suffer a lot of "not invented here" - wanting to write whacky stuff like ORMs etc. This turned out to be a very bad idea. "Not invented here" is a plague which afflicts developers and needs significant willpower to resist :)
Reinventing a wheel is ok but only if everyone else's is square.
Working on Unix systems, I think I would have learned a string manipulation language such as Perl or Ruby earlier instead of using shell scripts.
Of course there is a lot of things that can be done with shell scripts, but there is a gap with Perl which scales a lot more.
I've alluded to the webapp I had been tasked with recovering from novice Java "programmers" before in another question. This webapp used Spring Webflow and in a lot of places, since one of the coders was familiar with C/C++, he thought it would be a great idea to use a BitSet to keep track of what validation method to invoke in Spring's Validator through the bindAndValidate method of WebFlow's FormAction class.
This was emphatically not a good idea. As you may gather, it provided confusion while not saving any memory in the slightest.
So, a coworker of mine devised a system (while not reading the JavaDoc of the FormAction class) such that a particular validator could use the action state id of its current state to invoke the particular method in the validator to use. This seemed like a great idea to me (who also did not read the JavaDoc of FormAction at that time, I am not blameless in this), so I implemented a more generic abstraction for all validators based on his work. This was only used in three validators, however, because we were running low on time.
But, if either he or I had read the FormAction documentation, we would have known that all we had to do was set certain webflow attributes in the flow and the FormAction would have only invoked the validation methods specified. If I had known that, I would never have bothered making the abstraction.
Deciding to create the main application I'm working on using one-way code generator instead of creating a proper object-oriented system which can be easily extended later.
I wasted a lot of time delving into alternate operation systems, creating programs no one around here wanted to buy (OS/2, BeOS) or pay money for (Linux).
Now I listen first, what OS customers want to use, and don't even try to get them to switch to something else - the only effect of persuading them to switch is getting blamed for everything what might go wrong.
Agreeing to build a business-critical system that was needed - like - yesterday in Microsoft Access. Oh, it worked. Might have been better in the long run if it hadn't. The business is no longer a going concern, and I have always wondered if it might be partly my fault.
But then I remember to blame it on the management, who ought to have known better, and on the comedy of errors that was the executive and financier layer of the business.
I would have cleared my search history before I let my previous boss use my laptop. Linux + jobs + c just could not be explained away ...
Spending too much time thinking about abstracting the solutions and over-engineering, instead of getting down and dirty and just doing it!