|
Isn't every routine/function/method/class/program an "algorithm" of sorts? As for my own time much of it is spent watching the twirly blue circle in Visual Studio and occasionally the white screen of death. Then there are the many many many 15m builds and the occasional language error leaving me scratching my head and attempting to discern the cryptic not very informative compiler error message. - Cheerio
"I once put instant coffee into the microwave and went back in time." - Steven Wright
"Shut up and calculate" - apparently N. David Mermin possibly Richard Feynman
My sympathies to the SPAM moderator
“I want to sing, I want to cry, I want to laugh. Everything together. And jump and dance. The day has arrived — yippee!” - Desmond Tutu
“When the green flag drops the bullshit stops!”
"It is cheaper to save the world than it is to ruin it."
"I must have had lessons" - Reverend Jim Ignatowski / Christopher Lloyd
|
|
|
|
|
PaltryProgrammer wrote: Isn't every routine/function/method/class/program an "algorithm" of sorts?
Sure, but not an algorithm that takes a great amount of mental effort to develop. Just like every little shed is a "building", you do not to into a great "building construction task" that really takes you expertise as an construction engineer to calculate right.
I see myself more as a carpenter putting boards together, laying the tiles on the roof. Some effort goes on deciding the "floor plan", which pieces to put together and in which way, but for most things I do, that is really a minor part, both in hours and mental effort. The carpentry is the essential thing: Coding, debugging, testing, documenting. Not the architectural work.
|
|
|
|
|
As for mental effort, programmers are merely engineers. In my view there are three levels, i.e. to wit [0] scientists discover new knowledge, [1] engineers utilize these new knowledge to solve new problems, [2] technicians utilize the tools engineers fabricate to repeatedly solve the same problems again and again. - Best
|
|
|
|
|
How big is your cade base? I have a fairly big code base (50k lines maybe) and it takes about 15s, not 15m to compile on my 32-hyperthread CPU.
|
|
|
|
|
Approximately 15K lines mostly templates plus 1.5K lines test code. When this project is done pretty soon now I intend to return to a project finished some years ago 50K lines in C and convert to C++ w/ modern UI/GUI and many improvements. No way I will tolerate the build times for that size. I will have to get a proper development machine. My current horse and buggy is https://www.hp.com/us-en/shop/pdp/hp-slimline-desktop-290-a0035z[^]
|
|
|
|
|
Yes, I would say you need a new development machine!
|
|
|
|
|
I had your experience with business development.
With IoT it's all about stuffing everything you can into as small a footprint as possible, and I mean that, because once you get it to actually run on the hardware, you still have power concerns.  Unless you want the user going to the charging station once every couple of hours.
So algorithms are king. It's why I enjoy it so much, I think. After all this time it feels like *real programming* again.
To err is human. Fortune favors the monsters.
|
|
|
|
|
I worked with IoT for more than ten years. For my first programming assignment, I was given a total budget of 1200 bytes to implement Bluetooth DTM (Direct Test Mode). That job was no development of new algorithms, that was essentially given by the DTM spec. I'd say that two thirds of the work was shaving corners, trying out alternatative statement types, repacking data in different ways to save a byte here, a byte there. (If you have ever tried to implement Bluetooth DTM, you will know that 1200 bytes total is a rather tight limit!)
That is more like the way I experience IoT work: Shaving, rubbing off and polishing, and testing, testing, testing, ...
Did I ever, in my IoT work, develop some new algorithm that I could present in pseudocode form to an audience, explaining that this is the new algorithm I have developed for solving this problem that had no earlier solution? I have spent a significant part of my working hours and mental effort on finding out how to do it, at the conceptual level? The kind of mental activity that might keep your brain awake when you should be sleeping?
No. Almost all I've been doing has been stuff that, if written as a semi-abstract algorithm (by that I mean e.g. in pseudocode, independent of any specific implmentation) would be rather trivial in terms of algorithmic development from already well known state of the art. My working hours are spent going from the conceptual solution to a working, reasonably error-free, ready-for-sale implementation.
In my studies, the Systems Engeneering book claimed that if making a 'bare' freestanding 'program' to solve a problem takes 1 unit of work, doing the same solution as a 'program component' in a lager software infrastructure (where you have to relate to standards, interfaces, various conventions) typically takes 3 units of work. If you are making a commercial 'program product', with test procedures, documentation, support system, marketing and sales effort, it takes 3 units of work for the freestading program. Combine these two axes into a 'program component product', it takes the product of the two axes, roughly 10 times the work of making the bare, freestanding program.
My experience is that this is a fairly good rule of thumb. If you manage to do it significantly cheaper, most likely you are either ignoring the rest of the world and any infrastructure requirements, making a simple freestanding program, or you make a bare-bones delivery with no or very limited support, documentation, ...
Algorithmic development relates only to that bare freestanding program, and even there, it makes up a limited part of the work. As a developer, you certainly do not do all the ten units of work of a program component product, yet you have to relate to (at a resource cost!) technical writers, marketing people and management, who depend on information from you to do their work.
I guess I have been sleepless more from sales people and management than from problems finding an algorithmic solution to my problems!
|
|
|
|
|
My primary client had a career as an electrical engineer and now handles sales and interfacing with our end-end clients.
He's realistic, easy to work with and treats me well.
I'd say that two thirds of the work was shaving corners, trying out alternatative statement types, repacking data in different ways to save a byte here, a byte there. (If you have ever tried to implement Bluetooth DTM, you will know that 1200 bytes total is a rather tight limit!)
That's part of what I mean when I'm talking about developing algorithms - this sort of refinement necessary to make them work on little devices.
And I don't handle all facets of development and delivery. I do some of the hardware, and all of the software on these projects. I do spend a lot of time testing and documenting, but when I'm not doing that, I'm writing wicked code, like getting truetype to work realistically on a an esp32
To err is human. Fortune favors the monsters.
|
|
|
|
|
I only do line-of-business stuff, and the OP's experience pretty much mirrors my own. Despite my work falling under the umbrella of "computer science," I do not like to think of myself as a computer scientist (or even an engineer, really), I tend to reserve that term for the people who are devising new technologies and novel algorithms. I take the excellent, innovative ideas of other people and apply them more or less intelligently to the business problem at hand. I'm comfortable with being good at that, even though I'm certain I'm not changing the world 
|
|
|
|
|
I call this surfing on the down trough of the hype cycle.
If some new tech makes it to the 3rd iteration, that is a good time to use it.
|
|
|
|
|
For me it's 80% algorithm / 20% code.
Once the algorithm is clear in my mind (and maybe on paper) the coding part is easy.
If I can explain my approach to my colleagues - and they understand it, then I know I'm on the right track. If I can't explain it adequately or their eyes glaze over then I need to do more thinking.
|
|
|
|
|
Yes, I spent most of a year developing two completely novel, efficient algorithms, resulting in half-a-dozen U.S. patents. I'm "just a developer" but I happened to work at a company where a much more efficient algorithm became necessary because Moore's Law was making our product way too slow on modern circuits. To develop these algorithms, I also had to characterize the performance in big-O terms, of a dozen existing algorithms, including three algorithms we had previously developed ourselves.
In another instance, I had to reverse-engineer the inefficient sort algorithm a customer was using from the English description of a non-technical person, and then implement an efficient algorithm to sort his data in an acceptable time.
I have the same experience as trønderen, spending much of my life integrating known puzzle-pieces off the web into an effective, novel solution. But I have to be aware of algorithms to separate the efficient answers from the inefficient ones. There are recurring patterns underlying efficient algorithms that you can use every day if you are aware of them, and only thinking about and studying algorithms leads you to these patterns. You can tweak your code forever to make it faster, but the only way to achieve an order-of-magnitude performance improvement is to find a faster algorithm. It's just something I do.
|
|
|
|
|
The amount of think time is usually proportional to how much you "own" what you're working on.
As technical lead, you might spend all your time "thinking"; assuming someone else is doing the coding.
A system / app is just a big algorithm, IMO; but if you don't get the overall right, the little ones don't matter.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
At present, most of my mental capacity is spent on refining and adding to the implementation of my novel native-variable-length hash table, part of which is covered by U.S. Patent No.: 11,254,590. But I spent many restless nights trying to devise the basic algorithm that allows the storage of multiple record types directly in a hash table; after all, that has been considered impossible since the invention of the hash table in the 1950's!
|
|
|
|
|
... He opens Windows.
|
|
|
|
|
Shirley you meant he breaks Windows. 
|
|
|
|
|
So it be
|
|
|
|
|
Kind of begs the question then... what does Linus do when he passes gas?  Oh wait. It's open source, so he shares it freely.
I have an unfortunate familiarity with noxious biological emissions, as I own greyhounds. They are the world's fastest couch potatoes, and the emitters of the most foul odors  an hour or two after mealtimes.
Software Zen: delete this;
|
|
|
|
|
Tried changing their diet?
A lot of dog food contains soy beans.
|
|
|
|
|
If you think Greyhounds are bad, try just-weaned-kitten farts.
For such a tiny dribble of fluff, they can produce the most monumental, room-filling (and -evacuating) stenches. Usually when they get excited because you have gone to bed.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
For me, that is Perrier, a French story since 1863. 
|
|
|
|
|
A true story: Perrier virtually created a whole industry.
Back in the nineties, Perrier had over 90% of the bottled water market, worldwide. If you drank carbonated water, 9 times out of ten, you drank Perrier.
Then came the Benzene problem[^] - a small amount of product was contaminated with a small amount of Benzene, and the management sat on the info. A whistle blower didn't. A recall was needed to restore public confidence.
But ... back then, hardly anyone printed traceability info on product - certainly Perrier didn't. So to recover all the tainted water, they had to recall every bottle.
Not just in France.
Not just in Europe.
Not just in the US.
Every. Single. Bottle.
Worldwide.
It took weeks to get their water back on the shelves, and by then, the local manufacturers had ramped up production and customers had tried it, and wondered why they paid so much more for French water, when local stuff was as good or better?
After the crisis Perrier market share never got back above 10%.
And production directors trembled and shook nervously as they asked their production and maintenance guys what traceability marking their company did - and got the answer "None. You refused to give a budget for it". Huge budgets we suddenly allocated, lucrative cheques were written, and the coding and marking industry moved from a tiny market segment to a massive industry virtually overnight ...
In the mid / late '90s a UK biscuit manufacturer found that a flour sieve has broken on a regular inspection and could have released metal particles into the product. They recalled every biscuit that was manufactured on that line between 1/2 an hour before the last successful inspection and the time they shut the line, and because they traced properly, all they had to do was turn around a couple of dozen lorries and scrap pallet loads - not one biscuit reached the shops.
I entered Coding and Marking in the early '90s, coincidentally.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
That's a fantastic story! Thanks for sharing.
I'd read an entire book of that stuff. It's so instructive about how we've gotten to the world we have today -- hits & misses.
Coding & marking could be considered "boring" by some, but then explained in this way, it is fascinating. 
|
|
|
|
|
raddevus wrote: I'd read an entire book of that stuff.
A classic in the field is David A. Ricks: Blunders in International Business[^].
I read the first edition, published in the early 1980s, as a student, and found it very amazing and enlightening. It is now in its 4th edition, which I haven't seen, but hopefully it is just as good as the 1st. It focuses mainly on cultural and language issues. I don't remember coding and marking being discussed, but it would certainly have fit in!
For some reason, the book title is revised along with the text; the 1st ed was called "Big Business Blunders: Mistakes in Multinational Marketing". I believe the 2nd and 3rd may have had slightly varying titles as well.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
