|
You get paid for what you do, you can have fun in your spare time.
"Fun". Get out.
Bastard Programmer from Hell
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
In my many years of software and firmware experience, I've seen a lot of poorly written code. I'm pretty sure that most of it was due to starting a project with no plan for how it would be carried out, or how the implementation might affect people and plans in the future.
I once had to modify BIOS to allow a "chunk" to be added to the BIOS reflash image. That chunk needed to be checked and accepted by the firmware protocol in order for the running BIOS to allow itself to be reflashed. I could have modified the protocol to accept exactly the thing I needed to add, but I chose to add a small bit of data so that other, unknown (and at the time unneeded) "chunks" could easily be added in the future.
A couple of years went by and then a hardware design change led to the need to add a chunk of a different kind than the original. Instead of allotting weeks for the needed BIOS changes, we only needed a day or so, including testing.
FormerBIOSGuy
|
|
|
|
|
ABC.
Always Be Cutting. Always be measuring too, but that cyclic iteration of act/observe/revise is where it's at and it's where it's going to be for awhile and increasingly more so.
It doesn't matter what the language/tech is. Observe, act, revise. It's *your* basic operational loop as a programmer. It will also be the basic operational loop for anyone working with low/no-code.
That's not to say you can't "plan". But it is to say that "tests first" and the idea that you are ever going to nail down requirements up front flies directly in the face of all the agile practiced and preached. Make something happen. Satisfied? Repeat.
We're not punching holes in cards, knitting lace, or (hugely) time-sharing on "super computers". The computers reading our code now can tell us if it thinks our code is bad. You can reorganize/refactor anything fairly easily. Perfection paralysis is a demon. We sure don't carve our code in stone. AI/ML writes it in pencil.
As we move forward and we try to use ML/AI to supplement tech solution creation efforts, the same iterative improvement is key. It's pretty much exactly the process which drives ML itself.
So it will be particularly useful years on down the line to be able to prognosticate (and alter) why it is that our ML has made the choices it has. That may be ML that is writing code itself as part of a low/no code design tool. It may be ML that is doing/handling some part of your business domain. In either case, tuning is going to involve a bit of ML maths knowledge but even more domain-specific knowledge of things like tensors in your ML models.
|
|
|
|
|
It's all about dependencies, and ADUF (Adaptable Design Up-Front).
Don't depend on something that's not needed. And even if you think you need it, think again.
Don't make it impossible to adapt your code later.
Don't make a fragile design (changing code on place X should not break code on place Y).
|
|
|
|
|
Keep It Simple Write so it is easy to understand
|
|
|
|
|
Looking at the list provided. there are several I might have chosen ten years ago. Unfortunately today, I feel I must emphasize that somewhere someone wants to break your code and you must protect your users' data.
__________________
Lord, grant me the serenity to accept that there are some things I just can’t keep up with, the determination to keep up with the things I must keep up with, and the wisdom to find a good RSS feed from someone who keeps up with what I’d like to, but just don’t have the damn bandwidth to handle right now.
© 2009, Rex Hammock
|
|
|
|
|
|
I have lately decided to up my Java skills with modules, and to my disappointment I found literally no tutorial on how to do it in Eclipse with an existing project (especially trouble shooting things like jdk internals). I had so much trouble finding precise information (without rambling on how great and so on modules are). Every one had tons of manuals and documentation (i looked at Intelij Idea as well) all assuming I have already read five times the manual for modules and had an epiphany as to what and how and just needed to know where all the check boxes are.
Maybe this is simply because I learn more by doing, than reading, but it was a painful period.
Same goes for library APIs, browsing listings of packages, classes and methods is useless until I understand how author abstracted the API and what to expect from naming scheme. A solid amount of example code with some explanation of important details would also do wonders.
|
|
|
|
|
That way when you are told "That's not what we said." You have proof.
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
|
|
|
|
|
I always write an e-mail with a summary of most important decisions made and ask for confirmation if I understood everything correctly.
|
|
|
|
|
If you can't explain what it is doing or you find yourself using 'and' much, you need to simplify the code.
|
|
|
|
|
People, especially coders, thinking, that their codes are clear and readable in first view.
|
|
|
|
|
But it doesn't imply that you have to do exactly what they want. Or that you can not have freedom of action to do it.
But if you have your users in focus and you want to write a good software for them, many other points / good practices will come automatically.
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
0) flow of control (sequence/branching/return)
1) retaining state (variables, data structures)
2) looping/iteration/enumeration
3) conditional execution/evaluation
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
modified 19-Dec-22 12:33pm.
|
|
|
|
|
Just say NO I want my presents delivered on time.
PartsBin an Electronics Part Organizer - An updated version available!
JaxCoder.com
|
|
|
|
|
N lines of code contain n+1 bugs
|
|
|
|
|
are you sure it is linear ?
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
I disagree with those who have voted that coding should be fun. Coding is an engineering discipline which requires that attention be paid to a very large number of details. Addressing so many details is a challenge, doing so successfully is very satisfying, but I would not call it "fun".
All of the other options are important, but I doubt that most of them would sink in after a short course. Some of them can only be taught by painful experience. I would be quite satisfied if the only engineering discipline the elves mastered was proper use of version control.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Opinions on the definition of the word 'fun' vary. Mine seems similar to yours, but I can understand the expansion of the definition to include 'smarmy satisfaction' or even 'delightfully creative'.
'Fun' is like 'good' or 'pretty'; not particularly descriptive.
|
|
|
|
|
I agree software development is an engineering discipline. But that doesn't stop me from deriving great joy from it. I have fun every day at work because I insanely enjoy love what I do for a living, which is build software applications. And when I'm not working, I do the same thing for fun (https://ravib.com/freeware.htm).
But I don't subscribe to the theory that anyone can simply "learn" software engineering and become a software engineer. IMHO that makes as much sense as suggesting anyone can become a chef, heart surgeon, gymnast or race car driver. You need to have the aptitude for these professions. Unlike painting fences or making toast. I bet even I could be good at those tasks.
/ravi
|
|
|
|
|
There will always be someone smarter, faster, more efficient, and just plain better than you.
|
|
|
|
|
As was once pointed out to me: Even if you are a 'one in a million', there may be 1400 Chinese who is better than you. And more than 1300 from India.
|
|
|
|
|
Late deliveries disappoint.
|
|
|
|
|
The Elves should introduce a common santa timezone and snowball currency.
|
|
|
|
|
I don't subscribe to Xmas
Life should not be a journey to the grave with the intention of arriving safely in a pretty and well-preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming “Wow! What a Ride!" - Hunter S Thompson - RIP
|
|
|
|