What's the best lesson you have learned in your career? [closed]

Question

I think mine is "there's no such thing as a five minute job" - that programmers tend to be overly optimistic about development and that we should really think through a the implications before promising a quick solution to a problem and then diving in to code

Answer 1

There is always a better way to write your code.

No matter how excellent you find the code you write, you will be surprised how bad it is if you review it in a few years. Just because a few years before, you were unaware of some patterns you know today, or some language features you've learnt meanwhile, etc.

Answer 2

1. Think before you start coding.

2. There is nothing more permanent than temporary solutions :)

3. If it is awfully hard to solve a problem, most likely the problem itself is badly posed from the very beginning.

Answer 3

Your software will live considerably longer than you think it will at the time that you write it.

I started my career in the 80's. I started on software that originated in the 70's and was still being used in the 90's (maybe longer, I don't know for certain of its fate). Some of my own open source code is half way through its second decade.

Answer 4

Working well with others is very important.

"Show me your 'Go to guy' and I will show you your problem"

Slapdash Hero Coders - those who just crank out code with no regard for convention, readability or whatever anyone else is working on - can cause more harm than good.

Not saying that the people who can write tonnes of good quality code are bad thing. Just rare.

Answer 5

Learning new languages is part of the job

I learned about four programming languages in school back in the 80's but have used one of them in a job. I've had four jobs where I didn't even know the language I was hired to use.

Overall, I've learned and used professionally perhaps a dozen languages in my career, including FORTRAN, c, c++, c#, java, perl, Tcl, ruby, groovy, awk, python, sh, batch, DCL, javascript, and a few small DSLs. Doing a little math, I seem to average a new language every couple of years, though there's a lot of overlap.

If anything has been a constant in my career, it's change.

Answer 6

Software is never complete.

There is always some changes in requirements, improvements, bug fixes that you have to be prepared to handle. Thus, be flexible and accept the fact that "software is never complete" and always has room for improvements.

Answer 7

That would be the lesson of humility.

Answer 8

Keep studying every day. The knowledge of today is obsolete tomorrow.

Ironically this answer should be obsolete tomorrow too. But really, study hard one or two stuff and be certificated if it's possible, be the God of that things (maybe programming languages or system/network/database administration) and always keep an eye in other minor things, like other languages without importance to you.

I mean for example, be an awesome professional of Java and Oracle DB administration, but study a little of Python, PHP, C++, HTML5, Javascript, although no to a certification level. Study each web or language framework that exist. Study or try to have some (basic) experience with each database that exist, like SQL Server, MySQL, Cassandra, HBase, PostgreSQL, and the whole No-SQL world like MongoDB and CouchDB. Try to have some experience with linux administation and virtualization.

That's the biggest lesson that I learnt from my 16 years of experience. I was for almost 10 years a mono-language programmer, using Pascal in its era, and Visual Basic 6 at the beginning of the millenium, and a PHP developer since 9 years ago. But from then I learn that developers need to know at least a little of everything.

Answer 9

"If your math is wrong, you're toast."

Learnt it the first time several years ago. Learnt it again just two weeks ago.

Answer 10

I would say the best lesson I learnt is

"You should always go for the best approach possible and not your approach."

Answer 11

I have learned that best design principle is KISS (Keep it simple, Stupid!).

I have learned that keeping your code simple and clean should be the primary concern, and each team member should understand what you have code. The KISS principle states that most systems work best if they are kept simple rather than made complex, therefore simplicity should be a key goal in design and unnecessary complexity should be avoided.

Answer 12

"That will never happen" actually means "That will never happen until the first day in production"

Answer 13

It feels good to write top-notch, cutting-edge, clean code.

Even if I am asked to do some quick fix-workaround that would ruin the code base, I rather do it the good way.

Answer 14

If it ain't broken, don't fix it !

Trying to extend and improve stuff that already works may give you a big headache

Answer 15

There is no try

Lets say you have a task or bunch of tasks that are estimated to take 4 days. Then your boss or project manager asks if you could try to get it done in two days for some important reason. Wanting to be a good, flexible employee, you might be tempted to say: sure, you can try. Most likely outcomes from this is that you either miss the deadline, or you're going to do half-assed hack to get it done. And it's not your boss's fault for asking you to do it, that's his job. It's your fault for not saying no, which is your job.

You can't bargain with time. You can bargain with scope. Be professional and don't sell yourself short.

Answer 16

• Writing code is easy. Reading code is difficult. Even if the code is yours. So, whenever possible, go for readable approach.

• You aren't smarter than others. Don't ever think you're approach is the best just because its yours.

• Pay attention to WHAT is said, not BY WHOM it is said. Brilliant ideas might come for the most unexpected sources.

• Don't be lazy. Take your time to write nice code. You'll have to fix it anyway at a higher cost.

Answer 17

Don't use fancy OOP features just because you can! - YAGNI (You ain't gonna need it)

Use fancy OOP features because they have specific, demonstrable benefit to the problem you're trying to solve. You laugh, but i see this all the time. Most programmers never met an object they didn't like. I think it should be the other way around: these techniques are guilty until proven innocent in the court of KISS.