What are some of the most important points you learned over the years as a programmer?

There are many seasoned and programmers that have many years of experience on this forum, and could you share some of the points that you have encountered? LOL, these may have caused a few grey hairs to have sprouted on my head :slight_smile:

  1. No matter what new language is created, I usually end up programming in the same fundamental languages such as C/C++ for desktop or the trilogy HTML-CSS-Javascript for the internet
  2. Many languages attempt to reinvent the wheel
  3. When choosing a Linux OS, use one that has been around a very-long-time. New-and-Improved languages tend to lose steam and eventually become error prone.
  4. Keep a long list of organized programming code snippets. These are tools in your toolbox that will help you later in your programming career.
  5. Create things that you wish existed. It may be something as simple as a snippet of code, or a full program.

What other words of wisdom would you share with a potential young programmer? Some of these I wish I knew before I started programming. :slight_smile:

Edit: added 5

1 Like

Don’t try to make your current language work just like your previous language. Use the language as it was intended rather than force it to something it is not good at.

Determine the best places to find answers to your problems whether that be in the documentation, a forum, or internet search. After that, just don’t copy and paste the solution - figure out what they’re doing before using it.

Big projects are just a series of small projects that you piece together. Once pieced together you can fill in final details.

1 Like

When faced with a large overwhelming project design… do not attempt to solve it in one “lump”. analyze the requirements, and as BKenny said, break it into smaller managable segments that can be designed and tested independently, THEN stitch them together


FIRST write the algorithm out in English prose as comments
then fill in the code after the comments
and refine refine refine

unit test the crap out of every thing you can
when you find a bug, write a new test
make sure it exposes JUST the bug
fix the bug
see that the test now passes
lather rinse & repeat so your code evolves and gets better more robust & better tested over time

learn MANY programming languages
they will all be useful at one time or another

1 Like

Every single time. Desing looking at real users isntead of just guidelines.


Testing is everything although personally I find more value in a combination of “step through all new code with the debugger” and integration tests vs unit tests. Though the latter are good for your basic low level library code.

To me, software development ultimately begins with accurately identifying the actual problem and then clearly articulating it (to yourself first, then to others). And the actual problem is often – one might even say, usually – not what the client tells you it is. Early in my career I got burned giving the client exactly what they asked for, and then having it rejected. You have to learn how to tease out the actual requirements from the ill-conceived ones in between people’s ears.

Another aspect of this is to make sure you talk to the eventual front-line users and find out their actual pain points because the people that hire you have probably filtered and distorted the original problem statements.

1 Like

What the client thinks they want and what they really want are rarely the same thing

I’ve had many situations where I’d say “wouldn’t XYZ be better than ABC?” and the client goes “Duh… yeah it would”

1 Like

Definitely need BOTH kinds of tests - but I’ve lumped unit tests into one giant pile that should include integration tests as well
Low level library code being unit tested would definitely be the “performs this operation as expected” (ie/ ToString etc)
What you call integration tests would certainly fall into that pile as well in my mind ie/ the new payroll system pays people the correct amount but its still unit tests just done at a different level IMHO
I picked payroll as that one is something I worked on ages ago and pennies mattered :slight_smile:

Stepping through the debugger IS definitely useful - but in some tools you dont have that luxury (my payroll system above had no debugger like the Xojo IDE or many others do) So proper accurate tests were vital
A debugger + a full suite of automated accurate tests that are automatically run is additional assurances that whatever changes you’ve made haven’t broken things in unexpected ways

Both are useful for different reasons
At least in my opinion

1 Like

and don’t forget the all important “REGRESSION TESTING”
did something I just fixed, break something else?

Again I see well done unit testing as covering this off since they should alert you to any regressions / changes

FWIW I literally JUST made some huge changes to my Kitchen Sink project and all the unit tests in there alerted me to exactly where I broke things immediately and I went and fixed the code

Now all unit tests again pass using he refactored code

And, in the process, I added several new unit tests

1 Like

Great replies everyone. Thank you!

For debugging … when you’re stuck and can’t figure out what’s wrong … explain the problem to someone else. If you can’t find another programmer to help, explain it to anyone, even your dog. It’s the process of creating the explanation that will help you see the actual problem.


If I say so myself, going into a business, understanding how they operate and figuring out what their real needs are (as opposed to what they thing they are) is one of my biggest strengths. If I’m honest with myself, I’m probably better at that than I am at programming. Maybe I should just be a consultant and leave the development to others? :wink:

I do this all the time and it works great. I often write an entire function in English and then just fill in the code beneath each comment. Really gets your thinking straight and keeps it that way.

As my Wife can attest, this also works great. The number of times I start to talk to her about a problem and how I’ve been banging my head against the wall for hours with it, I get half way through explaining the issue and suddenly the penny drops and I scuttle off to fix it. She’s learnt not to even try to understand what I’m explaining to her and just be a sounding board.

We all need a rubber duck!

In our company we ask each other to be the rubber duck quite a bit. For us it means ‘I’m trying to figure something out and I just need someone to listen for a bit while I blather on - and if you have any insight I’d appreciate it’. Works almost all the time.


I was introduced to that as the “Intelligent Doorknob” method

I’ve worked with several door knobs
Few were what I’d describe as “intelligent”
They were more in the “sharp like sock” category

1 Like

This. Time and again, I’ve begun writing a big long detailed email to a client explaining the problem, and halfway through I see the answer. It’s actually become part of my workflow - I start writing the email knowing that it probably won’t need to be sent, but I need to go through the exercise to get the answer.


Yep. Programming is programming, the concepts are universal. Language is more or less irrelevant until you’re close to bare metal, and at that point I prefer assembler.

1 Like

If I may make a few suggestions, which are heavily influenced by the last handful of years.

  1. Pick the right tool for the job, and learn the language for that tool. If you wanna write apps for a specific platform, use that platform vendors tools and language. If you want x-plat… Well… That’s not my field of expertise, but I’d probably still recommend looking into a tool that’s provided by a platform vendor which can build apps for other platforms.

  2. Minimizing locked dependencies minimizes problems down the road. There can and will still be issues, but these are reduced and your product isn’t held back or unable to launch because someone in the dependency chain thinks they know better than the platform vendor. Having access to the source code for other dependencies, also enables you to solve problems or extend functionality in your own time frame.

  3. If you’re at the point where you need to compare tools and languages, check to see how well accepted the tool/language is. How much valid sample code is available online (outside of the vendors own site and forums). Has the language changed over the last few years, i.e. how likely are you to find sample code that doesn’t work? I love that I can find 20 year old Objective-C, C++ sample code and for the most part it is still valid.

Self publishing comments.

  1. Marketing is more important now than ever, more important than the tool or programming language. The rise of the “Curated” app stores, has lead to the death of organic discovery. No longer can you make a kick-ass app and by simply posting it to download sites, will people find it. Often when launching on an App Store, you’ll need to engage in some form of marketing otherwise your application stays hidden from the general public.

  2. Read the App Store rules, consider what functionality your application is going to need, how to accomplish that, are there any limitations in your tool of choice? In some cases, it would actually be quicker to switch tools (and learn a different language) early on than realize there’s a limitation or issue in your tool of choice that prevents your application from being distributed via the App Stores. I have one App Wrapper customer who’s re-writing their Mac application in a different tool, because there are limitations and issues in their current choice of tool, which prevents their application from even getting past the automated steps of App Store submission.

  3. On some platforms, its possible to publish outside of the vendors “App Store”. However, you should consider if it is viable. App Stores cripple functionality and the level of innovation you can use, but the general public prefers App Stores over alternative sources. 56% of Mac Users will only download apps from the App Store. If your app isn’t there, you’re limiting your potential audience.

After coding for years on end and using multiple languages I have to say that one should move to using no-code/low-code tools. Some are freeware and some are paid but nevertheless one can do more with less. So why keep on coding by copying and pasting code snippets from old code in existing project to new projects.

Even using frameworks force developers to repeat the same coding over and over again in different projects (boiler plate code as it is sometimes called).

My 2 cents.