Engineers · Programmer

What do you wish you knew after a few years into programming?

Svetlana Gluschuk QA Analyst

November 7th, 2017

My learning has been in stops and starts. Now I can feel the cumulative learning paying off. I'm also realizing there's SO much more to learn. What advice do you have for programmers just hitting their stride? Many thanks for sharing your guidance!

Gabor Nagy Founder / Chief architect at Skyline Robotics

Last updated on November 13th, 2017

I agree with @Adrian. On a related note: avoid code duplication if you possibly can. If you have absolutely no choice (e.g. you need the same functionality in multiple programming languages, or with very different SDKs/APIs), and you can't load a database, at least generate the code (variants) automatically.

Or, as I like to say:

if you have to duplicate, at least automate!

Marcin Kulawinek Software R&D specialist, can help with project or you can join my project

November 13th, 2017

"Do not start coding before you figure out at least 3 ways to solve the problem."

Stop, think and then start coding. Never in reverse order.

ramin sarmadi Developer

November 14th, 2017

Using modular pattern!

every entity should be written as module (component)

this keeps your code super simple to read and maintain

for example many developers keeps all models in a folder, all views in another folder and all controllers in another folder.

when your application gets bigger finding and changing code became huge headache

Carl Hunter Roach @CarlHunterRoach

November 19th, 2017


- writing code is cheap.

- one learns about a problem while writing code.

- maintaining and extending code can be expensive.

Be prepared to throw code away and start again.

Gabor Nagy Founder / Chief architect at Skyline Robotics

Last updated on November 8th, 2017

The most important lesson I've learned after many years is to always think a design through thoroughly, before you start typing code, even if it takes days, or a week or two.

This will save you a lot of time and effort down the line. Unless it's a trivial problem, I always ask myself: "is this a robust solution that will work well with all kinds of situations, even extreme cases, or am I going to have to redesign it after 5-10 years?"

Also: "am I going to be able to brag about this design, or is it a hack that I'll be ashamed of?"

Unfortunately, this mind set is in direct opposition to the "white board coding" skills commonly tested at job interviews, but it will pay huge dividends in the long run.

Hacks may be tempting, especially when tight deadlines are involved, but they can backfire and end up being the very reason deadlines are missed, or worse: the product may end up so bad that it fails in the market, and / or your company is sued out of business due to some damage your product caused.


A thousand hacks never add up to great software!

- me :)

Adrian Leishman Full stack developer and SEO expert with a strong business understanding

November 8th, 2017

I wish I knew to make classes and functions as generic as possible. Don't hard code anything (not even text). Always assume that the display (view) layer will need to change because of branding or template changes. Generic functions allow for reuse and smaller/simpler code.

Databases are kings. Changing a title in a database table field is far simpler than recompiling code and can be done via a user interface without the need for a developer.