SoylentNews is people
SoylentNews
acid andy (1683)
(email not shown publicly)
https://soylentn ... nonymous+Coward/
Rationalistic, dualistic, vegan, cynical, scientific hippie
Do you ever look back on code you wrote when you were young and maybe start to feel a little queasy in your stomach? A feeling of abject horror strikes you as you cast your eyes over the thrown together mess of naive kludges and cringe inducing comments, full of cocky, misplaced bravado. You might even have a similar experience, perhaps to a lesser extent, with code you wrote ten years ago.
You ask yourself "What the fuck--I mean what the actual fuck--was I thinking, when I wrote that code?" Back in those days, your ego was huge; you were sure you were a coding deity that could do just about anything. Your code was the best. Now, the scales have fallen off your weary, partially deteriorated eyes, and you realize you utterly and hopelessly fell victim to your very own Dunning-Kruger effect. Hang your head in shame, dude!
The flipside of all this in the present day is the loss of a certain amount of confidence. With experience, you set higher standards for the code you write today, but there's a danger of going too far the other way and falling into perfectionism. If you got things done back in the day by throwing them together quickly, you'll probably find it takes a bit longer now to write code the "right" way. For me, open source certainly focuses the mind on spending a lot of time on trying to make it clear, readable and to have some degree of sanity.
I tend to want to get things right first time, as much as I can, when I write code today. I know that taken too far, that goes against the principles of rapid (iterative) application development, but I don't like the idea of leaving code I might be a bit uncertain about in place, where it might end up being forgotten later. When I have to do that, I'll leave clear TODOs for myself to pick up later.
I just feel like crap that I don't get as much time for hobby coding as I used to, and when I do find moments to spend on it, because I've set the bar much higher for myself in the code I write, and I feel a bit less confident than I used to, it feels like it's that much harder to get into it and make progress (even if the progress I had in my youth was illusory).
(Score: 2, Interesting) by Anonymous Coward on Thursday June 16 2022, @04:56PM (1 child)
My coding skills have actually dropped over the last twenty years. I can't concentrate like I used to and I hate it. :(
(Score: 1, Funny) by Anonymous Coward on Thursday June 16 2022, @05:22PM
My first 10-years we produced some elegant code. At least I think it was... couldn't read a whit of it, today.
(Score: 4, Insightful) by DannyB on Thursday June 16 2022, @06:54PM
I first learned the concept of programming on an HP programmable calculator from the mid 1970s.
In high school I got my hands on BASIC and never looked back at the calculator.
It was fun to learn. I read and studied everything I could get my hands on. Wrote "large" and "complex" programs for my age and for the computers of that era. I was well informed.
The problem (Dunning-Kruger) is that I could do so many things in BASIC. I didn't see why anyone would need any other more complex language.
In college, I did well. I didn't care so much for FORTRAN and especially COBOL, but I was interested in compiled languages. I continued to look at other languages.
When I first got hold of Pascal was when I realized just how little I actually knew. It's not that I didn't absorb Pascal easily, it was that it allowed me to express complex ideas that I could simply not have expressed in BASIC in any practical way.
Prior to Pascal, I had already conceived of "dynamic memory" and "records or structs" in BASIC. Simply dimension a bunch of parallel single dimension arrays that are the members of the struct. Then one additional array that had a flag whether each "row" was in use or not. Each struct is a single array index that refers to the struct members in different arrays at that particular index. It would even be possible for one "struct" (group of array elements with the same index) to "reference" or "point to" another simply by an index of array elements.
In Pascal the idea was so elegant. Declare a record (or in C a struct). Dynamically allocate and dispose of them. Have pointers to them, etc. Despite patting myself on the back for my ingenuity in BASIC, I suddenly realized that BASIC was not the be-all, end-all of programming languages that I actually believed it was.
I similarly worked with Pascal for years until . . . I discovered Lisp. Then I had a similar experience. In Lisp it was possible to effortlessly allocate and traverse structures with much less code or effort than Pascal. And I didn't have to manage ownership of memory. (GC) I immediately realized that this eliminated the 3 classes of bugs which were the cause of most bugs in languages like Pascal and C. ((1) free something twice, (2) don't free it at all, or (3) use it after it has been freed) Like when I discovered Pascal, I realized Lisp allowed me to easily express much more complex ideas and implement them.
I then developed a much less biased view of languages. It seemed that many languages were especially good at some particular purposes and maybe less well suited to other purposes. That is why I have such lack of respect for the C programmers who dis Java. They really have not "got it". For Java to be #1 in popularity for almost 15 years, and even today still in the top 3 spots, it must be doing something right for someone -- especially when the place it is used most is in giant banks, corporate enterprise applications, and financial applications. And run on big hardware. But I have a separate Journal article about that.
BASIC was good for new learners. At a particular point in time where every byte and cpu cycle was expensive. I'm not sure I would expose new learners to it today.
I like the interactivity of Lisp and Python just as I did with BASIC. I like the rapid prototyping of dynamic typing. But OTOH, I like the long term maintainability and refactoring tools for languages with strong static typing.
If there were one perfect programming language for all purposes, we would all be using it already.
How often should I have my memory checked? I used to know but...
(Score: 4, Interesting) by turgid on Thursday June 16 2022, @09:16PM (6 children)
I was going to write a journal entry just like this the other day! But let's think.
I'll tell you my story. I've always got great ambitions and ideas for cool code I'd like to write. In the working world, we have to write what The Man pays us to write, and how he thinks we should write it, whether that's a good idea or not.
We do our best to suggest better ways to do things where we can see them, and we hoover up good ideas ourselves when we see them too. There are times when we really want to do stuff and we manage to find some time and energy in our own time to at least chip away around the edges.
We live lives, which take up our not-at-work time, and 95% of that is stuff we just have to do. That's life. So we fit in the stuff we want to do around that (like trying to learn to play the guitar - for the 7th time) and/or personal coding projects.
Personal stuff is cool because you can try our all your own crazy ideas, frob with new languages and indeed do some things to a higher standard that Company Policy (The Man is a bit slow on the uptake). In the meantime, life goes by and we grow up.
Now for some cliches and trite buzzwords. With a bit of luck, we'll always keep learning and growing, until we get to a certain age when dementia or something kicks in. We don't know what we don't know and no one can know everything. People are still learning stuff. So what can we do?
Use the Scientific Method. Seriously, it works for code as it does for everything else. In the old-fashioned world, people approach coding like doing Maths. Coding is far too difficult for that. It needs to be treated like an experiment instead.
Here's the thought process. "I'm going to write some code to do a job. The job is to buy me something, for example, a more pleasant life (automating tedium, producing something nice) or buying me time (doing something faster that I'd have to do myself). What can I possibly do first to get me a step along that way? What can I implement to the point of finished, tested, working right now, in the space of a few minutes?"
You'll probably end up writing a couple of lines of shell script.
Great, it's done a very specific job, automated something and therefore saved you time. Bonus points if it accelerates your journey to the next step.
What's the next thing I need to do (use case)? How can I make it simple? How can I prove I've finished/got it right? Can I make an automated test so that later I can come back to it and change it with confidence? So can I put it in some sort of harness to protect against unintended regressions in behaviour?
If I can do that, I can narrow down the behaviour it really needs to have, that I really need to implement, to cut down the amount of code I need to write, to reduce the effort, to reduce the scope for error, to keep the tests passing, to be able to easily add new tests for any new behaviour I discover I need to implement.
And I need to have a way to make it all quick and easy to do, as easy as typing "make" and having all code compile and the tests run.
Then I'm in a situation where I have a nice feedback cycle where I'm implementing the bare minimum, and therefore simplest and least buggy, code to get the job done. I can refactor with ease and confidence.
Back to the Scientific Method: the tests are there to expose flaws in your theory (your code). The more your test coverage, the better tested your theory. The more corner cases ("exceptions to the rule") you cover and pass, the better.
Follow those principles and elegance will naturally follow.
Tiredness is a thing. Writing code is surprisingly tiring. Even just an hour in the evening can really take it out of you. Don't push yourself too hard. Automate.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 1) by khallow on Thursday June 16 2022, @11:26PM (3 children)
It depends on what you're doing. But if you're doing anything interesting sooner or later you'll need to do some engineering too, if only to do the science faster and better.
(Score: -1, Troll) by Anonymous Coward on Friday June 17 2022, @06:40AM (2 children)
And this, khallow, is why you fail. Cutting corners for money. It never ends well. Bend over.
(Score: 0) by Anonymous Coward on Friday June 17 2022, @07:00AM
True, cutting specific corners with repeatable precision and in full knowledge of the ensuing effects is all that is about engineering.
It is damaging only when at least one of the two things is missing.
(Score: 1, Touché) by khallow on Friday June 17 2022, @11:38AM
You're the only one who said anything about money.
(Score: 0) by Anonymous Coward on Friday June 17 2022, @02:43AM
I wrote a revealing, inspiring reminiscence for here. Then I read the tag at the end of your post.
(Score: 0) by Anonymous Coward on Friday June 17 2022, @06:32AM
Unlike the laws of nature, the requirements against a software will evolve in very short time (at human civilization scale, more so at geological ones).
The only elegance that one can have is the elegance running an almost continuous code refactoring (or the elegance of a dead-in-3-years software).
Adopting an iterative process (nothing wrong with it in healthy doses) if you don't reach a deadend, when you need to throw away a significant percentage of your "evolved over countless iterations code" and write it afresh, then your code is not used as intensely or by as many people as you think it is. (if you need to throw everything and start from scratch then you're a noob, not a software engineer).
In the course of past 2 years I done it 3 times - a good thing the pandemic allowed me to WFH (and gain longer and uninterrupted coding hours) and that my age allowed me to push back the management with their "3 standups/week, then 1 planning and 1 review per 2w sprint, and don't forget your user stories needs the DoD - definition of done - that describes what they'll deliver to the user".
Instead, my approach resulted in 2-3 months of nothing-useful-to-the-user implementation followed by all of the over 40-50 user stories delivered in one additional month.
* First iteration worked fine on one platform - took 3mo to code and 2mo to adjust to the special requirements in production.
* In the second iteration, they wanted two more platforms being supported - refactor a good chunk of the code in abstracting what a platform is, then implement the support for the other platforms as a plugin. Took 3 month refactoring and 4 months to reach the stability in production - mostly because the two other platforms are as finicky as any mobile device platform can be.
* The third iteration brought in the "But I need to know when something goes wrong sooner than the repeatedly failing jobs start to be aplenty". Well, tough, can't expect the detection of troubles to run on those 4core 2GB RAM $300 NUCs. So, 3mo of refactor the code to spit out "before/after operation success/fail events" on an event bus (aka message queue) and then run the "RealTime troubles detection" logic on computers listening to some tens-to-hundred of such NUCs. The (my feeling of guts) 2mo for production hardening are about to start.
After that, implementation of detecting different types of troubles are not going to affect the core of the system.
But...
* I predict next year they'll come to me and ask for "Ye know? This and that kind of troubles are more frequent, can we do something about recovering from them?" Knowing from a long SWEng experience what I know (even if they don't know it yet), I created already a "troubleshooting" interface (with just a handful of recovery operations) but I accounted for its presence in the grand scheme of things (new internal states and care to not trip over them). When they will come to me, it will be again a "Fine, I'll work for 2-3 months building the infrastructure code as an architectural piece that will address the mitigation. Then the last month I'll just customize the recovery from your troubles on top of it. Not only that, but other types of troubles of the same nature you come with, I'll be able to answer in days to a couple of weeks max".
And I'll be right with the second part of the promise until solving the new types of troubles are stepping out of the model that can be supported and require different approaches - (yet to be learned from experience). When (not if) that time will come, I'm mentally prepared to throw away a significant part of the code and refactor it.
(Score: 4, Funny) by krishnoid on Saturday June 18 2022, @02:09AM (2 children)
Well, you were probably too drunk. Or not drunk enough. I mean, they didn't know about the Ballmer Peak [xkcd.com] yet, so don't beat yourself up too much.
This is why comments are helpful. At least you can hold your younger self's hair out of his face while he's barfing in the toilet and get at least a perspective on the comments. We've all seen enough code without any comments to curse those who didn't even give hints as to what they intended when you need to maintain it in the future.
(Score: 4, Funny) by acid andy on Saturday June 18 2022, @03:34PM
You're probably right actually.
And the fortune says:
Master of the science of the art of the science of art.
(Score: 2, Touché) by Anonymous Coward on Sunday June 19 2022, @07:22AM
Comments deep into post-Ballmer-Peak territory are as useless for anyone as the code they provide an "insight" into. Don't ask me how I know.