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
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
Many languages attempt to reinvent the wheel
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.
Keep a long list of organized programming code snippets. These are tools in your toolbox that will help you later in your programming career.
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.
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.
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
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.
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
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
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
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?
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.
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.
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.
If I may make a few suggestions, which are heavily influenced by the last handful of years.
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.
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.
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.
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.
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.
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).