|
In a recent article 'The evolution of low-code/no-code development', a reference was made to Apples' Hypercard. It's successor (Supercard) was a much more robust development environment.
I developed a complex medical training simulator using Supercard back in the late 80's. Believe me when I tell you that (a) both suffered from the Apple 'bomb' periodically. Press run, ding, power off, power on; and (b) neither was a low code/no code solution, IF, you were developing anything useful.
Apple had this toaster approach that they did not need to give you any reason for a failure - just blow up. Not sure if that is still the case, since Apple has never breached the enterprise environment.
Carry it forward in time, and you would see that 'cards' were similar to todays Visual Basic/Visual Studio 'forms'. But there was a lot of coding behind the scene to make thing work - just like today.
|
|
|
|
|
Except I no longer have a door to close thanks to those w**kers in HR who decided everyone can work in a noisey distracting environment.
Luckily for them I can mentally block everything around me out pretty easily when I'm concentrating (I don't even notice people come up to my desk and start asking me stuff - and no, I'm not wearing headphones, my brain has just blocked/filtered all that stuff out).
Then Covid came along and just about permanently working at home with no distractions save the wife and she's busy writing a book so no problems there... 
If your neighbours don't listen to The Ramones, turn it up real loud so they can.
“We didn't have a positive song until we wrote 'Now I Wanna Sniff Some Glue!'” ― Dee Dee Ramone
"The Democrats want my guns and the Republicans want my porno mags and I ain't giving up either" - Joey Ramone
|
|
|
|
|
I work better in a small group of focused developers, by focused I mean working on the same products. This keeps me away from the SQUIRREL! syndrome and my prodigiuos ability to procastrinate. It also smoothes over the anxiety when a solution doesn't work as expected and aids me in having information and sounding boards all around me.
I can work alone but I still need some way to be integrated into a team, otherwise I procastrinate and get easily distracted (aka hyperfocused... on something else) then bored.
GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X
|
|
|
|
|
|
let us get our heads down and work, but give us a way to quickly ask each other for info if we need to.
|
|
|
|
|
Slight edit to the correct answer...
|
|
|
|
|
My cat insists on my company so she can doze on my non mousing hand.
Joan F Silverston
jsilverston@cox.net
nhswinc.com
|
|
|
|
|
A cat is the ultimate partner for Pair Programming!
|
|
|
|
|
You mean the purrfect partner.
// TODO: Insert something here Top ten reasons why I'm lazy
1.
|
|
|
|
|
About 10 years ago I was working from home.
I had shelving to the right of my desk. On one shelf I had a cat bed. The two male cats in the house would take turns sleeping in it for a few hours. It was nice that they wanted to be close. I miss that.
My wife is allergic so we decided to not get cats again after my son moved with his and the the other cat passed away.
|
|
|
|
|
One of my cats is sleeping on a blanket on my desk and the other in my second office chair. Companionship without distraction. Perfect pets for devs!
|
|
|
|
|
I know that I'm running the risk of being waterfall shamed when I stress that problem definition does not start with typing "int main((int argc, char *argv[])" in emacs.
Well ... In socalled "agile" development, I guess that it is. In less agile environments, you try to identify the purpose of the software, which task or problem it should solve, before you open up emacs, or for that sake, Visual Studio.
You just can't lock yourself up in a closet, hoping to understand the customer's needs in solitude. You must communicate with the customer. And you may need to brainstorm with your co-workers about the best way to cover the identified needs.
So the question is: At what stage do you lock yourself up in that closet? After an informal brainstorming in the coffee corner? Or do you take it as far as sketching data structures and code module structures on a whiteboard? Do you discuss with your co-workers how to break the design down to individual code modules? Do you consider alternate algorithms with them?
How far will you allow for second thoughts on the solution to be built? If you really get down to module structure, reasonably detailed data structure descriptions, and choice among alternate algorithm, then you may very well lock the closet door behind you and start coding.
If you consider "coding" to include definition of external interfaces (including the "user" variant), which standards to adhere to, how to structure your code modules and data, how to do the testing, and which algorithms to use, and with that lock the closet door behind you to start on the "coding" task, then I am in strong disagreement with you.
I am in favor of airing second thoughts on selected alternatives long before you upload your code to Git and open it for review. Yes, I know that the "agile" way is to hold back any discussion of the architecture until the house has been built. So tell me that this proves that I am about to dive into the waterfall. Yet, I prefer to have at least some sketch of what I am going to build before I build it. And that sketch should be discussed with others.
Why are not homes built according to "agile" principles for development? Would you call for a carpenter to build you a new home, telling the carpenter to do his work in the same "agile" way as you do your software development work?
|
|
|
|
|
Yes, I see different phases in software development like UI, Design, testing and "coding it out".
Press F1 for help or google it.
Greetings from Germany
|
|
|
|
|
product development people talk with customers. programmers program.
|
|
|
|
|
Left to my own devices I work very well, designing as I go. I'm pretty good at doing JIT architecture.
However, I tend to agree with you, if nothing else for the sake of clients. Projects begin (well not exactly but close to the beginning) with something like functional requirements gathering. You have to talk to the client to produce that.
When I'm doing something like coding an NES emulator for IoT (like I am now), I just code. It's liberating.
Real programmers use butterflies
|
|
|
|
|
When I make my own stuff, I tend to start with the documentation - that is my version of rubberducking. Forcing myself make a lucid, consistent and complete description of how you are supposed to use the software really helps in detecting inconsistencies, incompleteness, and unforeseen complexities.
Frequently, I create for myself an imaginary scenario where the planned product/solution is presented for a qualified audience, which is invited to ask questions or make critical remarks, and the presenter must do his best to defend the chosen solution. Being my private scenario, I obviously control both sides, both the audience and the presenter, but as the whole idea is to let the presenter really be confronted, nailed down, I try to investigate what sort of inquisitive and critical remarks could come from a well educated audience - and for the presenter to give fully satisfying answers to why it wasn't done another way, the specific arguments for the selected solution, how future functional extensions will be integrated, and so on.
To provide sufficient answers to the inquisition, I often have to dig far deeper into "prior work" than I first planned, and fact is that several of my initial designs have been drastically revised after such "events", meetings between a marketer and customers who really think that a competitor may have a better solution.
The good thing is that after meeting all these imaginary customers, I have a chance to correct and improve my own solution without revealing all my prior bad ideas to anyone
|
|
|
|
|
I don't want to sound cocky, but honestly, I have a knack for conceptualizing at dizzying levels of abstraction without falling back to the pen, and I think around corners pretty well.
For example, I designed and built GFX Forever: The Complete Guide to GFX for IoT[^] well before I wrote the documentation and the architecture has withstood the test of time. I do have to rebake the thing from being a header only library for reasons, but aside from that there have been no major design changes.
It's being used commercially now.
Design is just something I have such a gift for, I can do it in my head, if not my sleep.
But the downside is documentation becomes an afterthought, even if the design is robust.
However, I've mostly nicked that issue by writing technical articles after the fact that cover using my code, and I think the reception speaks for itself. So I've got a system in place that I use personally that works commercially. If I was working on a team, I'd do things differently.
Real programmers use butterflies
|
|
|
|
|
But when I was working, it was partly the small team and partly the access to people answers.
However, the one thing I found in 30+ years software development that makes code better is being around smarter people.
In this sense, 'smarter' doesn't necessarily mean more intelligent, but smarter in terms of understanding the problems you're trying to solve. Whether it's business people really understanding the needs, or us geeks really understanding the platforms we're developing for, having that made me produce better code.
|
|
|
|
|
So long as no one is actively seeking my attention, and as long as there are no emergencies or other exciting happenings going on nearby, I'm good.
|
|
|
|
|
No No NO! If there is even muted conversation going on in the room, my attention will invariably get sucked into it.
|
|
|
|
|
Alone but in "normal" SOHO. I am not easily distracted.
I am presently "touching up" some old VBscripts, not much concentration required there.
>64
If you can keep your head while those about you are losing theirs, perhaps you don't understand the situation.
|
|
|
|
|
It depends on how well defined the task is. If it's documented and understood well then I prefer peace and quiet. But there are also times when being in the office with other team members is helpful e.g. when questions need to be asked on how something is supposed to work.
|
|
|
|
|
Well caffeinated.
The less you need, the more you have.
Even a blind squirrel gets a nut...occasionally.
JaxCoder.com
|
|
|
|
|
If caffeine's not a food, it seems I've been doing it wrong!
|
|
|
|
|
So you're going with direct intravenous infusion then?
Software Zen: delete this;
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
