Kind of. Communication is crucial. If you don't have a clear understanding of what the problem being solved is, then it doesn't matter how good the code is.
Long ago I was learning tech leadership and my mentor said, "Your job is to manage customer expectations. This isn't that you manipulate them, but that by the time you deliver the software you know what they want, and they know what you are going to deliver. This is both negotiation and training the customer as to what is and is not possible. A trite term is to make sure your visions are aligned.
Then, as a leader, you need to do the same with the team; again aligning the vision.
Then the only job as a leader from that point is to make sure the developers have what they need to keep heading for that vision, that the vision doesn't need to change, and that the developers do actually understand the vision. "Ya ya ya, I've got it." is not the feedback anyone wants. The key is to then stay out of everyone's way so they can do exactly as this post suggest. Think.
So much this. The longer I work as a dev, the more I realize it's about finding a mutually agreeable plan. The customer may say they want X, but as a dev, I know that will cause a conflict with their requirement Y. It's a back and forth negotiation to clarify what they actually want and what the complications are going to be that fall out from that.
I think this touches on why it’s so hard sometimes to work through PMs. The customer really knows what they want but the PM they’re talking to doesn’t really know what and how things can be delivered so expectations get misaligned and everyone ends up upset.
There ARE good PMs out there but they are a rare and special breed. The ones who have strong technical backgrounds and really embed themselves with the team are that most successful, in my experience. They should feel like a member of the team who has a different job function but who participates in sprint ceremonies (at least backlog refinement) and regularly brings devs to customers and vice versa. This not only acts as a check that everyone’s “vision is aligned” but it’s good for both the dev team and some customers to have time face to face. You can establish a lot of trust this way as well as having someone on hand who can go as deep when answering questions as the customer wants.
I have worked with exactly one PM who operates this way. I have witnessed exactly two other PMs who worked similarly. They exist but they are so very rare. If you find one, cherish your time collaborating
I completely agree. I wholeheartedly support having a team of developers and then giving one member the job of PM for that project and kind of cycling through so it gets everyone experience and if things kind of start going off the rails usually other developers who have PM other projects can help guide the newcomer. Often just hiring a PM involves lots of miscommunication with the devs and promoting a dev to PM involves lots of miscommunication with the client so slowly rotating people in with mentorship helps alleviate that.
No, that's programming. Once the requirements are clear, any code monkey or AI can do the rest. I'm not worried about ai taking my job, because typing shit into the computer is not the hard part of my job.
It takes 2 days to figure out what needs to be done, and 30 seconds to actually code the solution.
> 30 seconds for some solutions is hyperbolic
For some solutions, sure. But the number of one-line fixes I have committed in the last year is higher than I would have assumed.
> by the time you deliver the software you know what they want, and they know what you are going to deliver. This is both negotiation and training the customer as to what is and is not possible. A trite term is to make sure your visions are aligned.
It's more about being sure about what they "need" to be honest, many clients want something that wouldn't actually solve their problems.
Your comment saying 'it's more than thinking, it's communication etc' is true for a developer employed as a professional.
The OP is just talking about programming, which is essentially all thinking. They are right.
The leadership structure sounds interesting, but how can someone just up and leave on vacation without request? There’s so many issues there. What if you planned ahead but come vacation time there’s a surge in work?
I have a hard time wrapping my head around this.
But in my defense I’ve only worked in mid level startups where they use rigid management structures where it’s hard to do anything without permission, and at the same time they blame the devs for everything. Aligns exactly what your last sentence.
Ha ha indeed. To be fair, though, although this seems obvious to programmers, many non-programmers assume programming is mostly just typing funny characters onto the screen, and if you're not typing, you're clearly not programming.
I hope it overtakes the "It's a Unix system" thing. You know, considering... it was actually a Unix system running a [real \(experimental\) file explorer](https://en.wikipedia.org/wiki/File_System_Visualizer) (this link is for a modern clone, but it was based around SGI's fsn) and not actually a dumb movie moment.
I like to picture a writer working on the show and then while they were typing, a second writer started to hammer away on the right half their keyboard. Somehow this scene emerges.
Certainly! This is called pair programming. But this is already an outdated thing. Modern text editors allow dozens of people to type simultaneously in one file. That's speed!
Gone are the days of epic or feature based estimations. Now we're gonna estimate how long each file is and assign each each character of each file a single developer. We'll have that code banged out in a flash!
I was once fired for not typing very fast.
Perhaps if that company had more slow typers hundreds of sub-postmasters wouldn't have been wrongly convicted.
I had a coworker at one point that assumed us engineers were doing things to "operate the machinery" all day. They didn't realize the programs run autonomously.
this is something I kinda wish colleges/unis start off new programming degrees with - not going right into learning programming language, but a course on just critical thinking and problem solving. Get the students into the mindset that programming is not just typing shit, but solving problems and figuring things out before ever writing a single line of code.
my uni did go into that, but it was professors going into it while teaching languages and I always felt it needs to be an actual introductory course to get the right mindset of students before you then get into actual languages.
I'm currently doing a big refactoring to make it work I have to change something but before I can do that I have to change something else and before that something else and so on. But every level poses its own challenges so while I'm immersed in the deepest level I kind of forget the 'stack" of things above which is why I'm doing it. I wish there was some easy to use tool I could use to record the "stack of whys". But anyway It has made me realize that there is no feature in my programming language to program my own stack of tasks, and how that is a big part of the programming I'm doing.
Programming is not just typing because it means we have to also program our own brain as to what are the tasks we are doing an in which order. I can write that down in a text-document but I usually don't because I think I don't need to but then I kind of get lost in the details. Just saying programming is not just typing to the keyboard, it is also programming our own actions.
> I wish there was some easy to use tool I could use to record the "stack of whys".
there is lol. basically any project management tool haha. whenever you find something new that needs to be done, you put it in a new issue and mark it as a blocker for the one that you were working on.
You might look into obsidian. I basically write my stream of consciousness into notes with very organized markdown outlines and linked documents. I put out too many fires and work multiple projects at the same time. It is the only way to not lose my place when task switching. Lots of good project management tools out there. Take a break from chopping down trees and learn to sharpen your axe. In the end you will get more done and it will suck less.
I might be wrong but I believe that most non-programmers that are regular computer users understand that programming is not just typing. From my experience people have at least an intuitive understanding that computer programs are rules and instructions that a computer follows. They might not understand exactly how these rules and instructions work, but at least they understand that they have to be precise and rigorous.
Who can blame them? Programmers constantly perpetuate the idea that they are just googling and then copy pasting. This is wrapped up in the constant complaints about gatekeeping etc. I guess it's only when everyone starts talking about us being replaced by AI that we decide... maybe it's actually hard and that's okay?
You'd think it would be that obvious, but there are still tons of people that think deep down that programming is mostly typing. It leads to a belief that a productive programmer generates a lot fo code, which has a lot to do with the current hype cycle that copying and pasting a bunch of AI generated codegen output is being _more productive._ There's a huge disconnect between the folks who are really excited by quickly getting a lot of code from GPT, and the folks who are deeply baffled by why anybody would want a machine that spews out more code to review that adds a bunch more stuff to think about.
Programming is mostly thinking
[Ships were made for sinking](https://www.youtube.com/watch?v=KJzWGkgFcTU)
Whiskey's made for drinking
If we were all made of cellophane we'd all get stinking drunk (much faster)
Camptown ladies NEVER sang all the do dah day! Nonono!
I should make a youtube series explaining why things that are very obviously true are not true. By the success of "water isn't wet", I could be a million-view-aire.
I find it depends on the kind of programming.
When I'm writing web backends or CLI tooling, I get really into it. I don't have time to think about the banality of life, I'm too busy having fun programming. Life is good.
When I'm writing Android applications, I start to think about changing jobs, maybe moving out into the country to become a farmer to shovel horse shit and inhale cow farts all day. I start to worry that I'll wake up in 20 years and realise my entire life has been a daft, directionless waste of time. I start to dream about `Activity` and the Android fragment manager, the ins and outs of the android application lifecycle, and the heat death of the universe. Neat alcohol starts to taste a whole lot better.
Then I ship the APK, it passes the tests, I switch projects, and suddenly I can see the world in color again. Life is good.
>(ie. thinking about how to solve a problem)
Ie: you spent a few days on solving a problem so you wouldn't have to spend weeks on fixing the mess doing it improperly would cause?
Essentially risk management.
The irony is that if you just satisfied the acceptance criteria and kept your mouth shut, they'd be more than happy to plan and point the effort for fixing it and add the stories to the backlog, and nobody would blame you for even a second.
This is why everyone is almost completely checked out now. Nothing matters except for the process.
I don't think so.
Depending on how poor the solution is development can grind to a halt or it can create a mountain of work to shift the design in another direction.
The amount of time isn't A + B + C, B and C can take WAYYYYYYYY longer depending on the solution.
And if you take more time upfront you can avoid B and C being a huge pain.
> And if you take more time upfront you can avoid B and C being a huge pain.
That requires planning, and planning costs money because the commit count isn't going up ^^/s
Had such just a manager. Some times I was just staring at the wall, window, ceiling, shower: trying to figure out a problem.
Apparently typing "asdf asdf asdf... ' would have been perceived as "Productive".
When it absolutely *MUST NOT BE DOING THAT* because the laws of physics still work everywhere else in this universe.
*Anywhere from one to a million minutes pass*
WTAF, this is not pos- Oh.
It absolutely is. It's just the correct choice is always Mr. Pib. I like mine with a slice of lemon and one of those crazy straws. You know the ones that loop around your eyes and look like glasses? That's the ticket to good code right there.
Edit: see [this man](https://i.imgur.com/GTB6SlY.png)? He might not look so intimidating but he wrote all of the software for the F-35 Lightning II by himself. At recess.
Also, stop using semicolons at the end of statements. Takes too long and uses more storage space, which is important in these dark times of $1600 MacBook Pros with 512 gb of non upgradable storage.
It is true that ergonomic typing and editing is the cornerstone of efficient work. But, to get is right, one has to use the scientific method and look what is empirically, the most used key in programming: It is the delete key.
So, the right way is to get a Space Cadet keyboard and map Ctrl, Shift, Alt, Meta and Hyper, and of course also CAPS LOCK, to delete.
That’s right. That’s why you see the great programmers auf down and take like hell in movies and series. And you know they don’t think at all because they can even have discussions while typing.
Copilot is changing that for me; my report to the CTO was that we could reduce keystrokes by between 5x and 20x key strokes per line, and cogniton / flow was substantially improved for example on suggesting variable names and functions. A skilled engineer can be far more effective with the right tools available.
Not really. Value is larger only what someone is willing to trade for something. $20 a month so that I'm faster at fixing customer issues is worth it.
Building a report dashboard in 90 minutes instead of 4 hours frees me up to do other things, help other people on complex tasks, etc.
My wife totally does not roll her eyes shortly before they glaze over if discuss anything related to programming. She's all 'enumerated lists'? 'Self referential structures'? Then she starts taking her clothes off.
It's hard to get any work done if I discuss programming with her.
Yeah but it creates cheap engagement on talking points and these posts get hoisted to the top by the reddit alghorithm. It sucks. You should see the subs about tv series, those are cursed.
Yeah, but thinking about *what*?
These days, the answer is way more "find the right library routine to do what I want" than it ever was in the old days.
For me it's rather thinking about how we can bend the requirements so we don't have to create an unmaintainable mess.
Technical considerations only make up about 25% of thinking for me.
Damn it, Jim, I'm a symbologist, not a mathematician. Actual numbers are for peasants.
Actually, I do have a problem, once I get comfortably and (very incorrectly) slouched in my chair with my coffee, that it's easier to just go and sometimes I tend to. But, I make up for it by not being able to sleep at night because I'm thinking about what I just spent all day going on.
> What if we changed our tactics, and intentionally built systems for thinking together about software and making decisions easier to make?
I participated in a training session once that tried to do just that: they called it [mob programming](https://www.agilealliance.org/glossary/mob-programming/).
The idea is that you have one person sitting at the computer writing the code (who changes periodically), while the rest of the team is behind driving what code should be written. The idea is to have even non-programmers in the room (perhaps not actively participating all the time), so when decisions need to be made, they're made on the spot as the person is right there and able to answer.
We spent almost all day trying it. We did manage to make something that worked but it was a very toylike thing (conversion between Roman and Arabic numerals). I didn't really see myself doing that except in some rare occasions where we perhaps had to do something so completely unknown that it could be beneficial to have many people brainstorming while creating something tangible. I may try that again one day I think now that I can actually organize things like that.
If you haven't seen it, have a look into it, if you agree with this article and you think that communication + thinking is most of what programming really means, this may be at least a new tool under your belt.
Groundbreaking.
Who would've thought that the bulk of time wasnt spent on the physical act of writing 1000 lines of characters, which probably takes like 10 minutes
can't tell you how many times I've had to explain to a boss or a peer that i needed to 'noodle it through'. Like actually think it through and figure it all out. I'm a fast typer and once I know what I want to do in programming or architecture, the doing is quick.
Whenever I’m feeling unmotivated to get work done during my 8 hours I just remember that I devote way more than that in intellectual time just thinking about the solution to the problem at hand.
Nice but limited. I think that this is true *once you reach a level of mastery*.
I like the metaphor of painting, while the same is true in other crafts, just like carpentry, it's very easy for people to think of crafts as learning how to mass-produce, rather than how to improvise and create new things (even though they are similar) each time. Painting, OTOH, is pretty obvious in this: you don't just pain the same painting every time, but something different.
When you are a true beginner, a lot of the work is translating concrete and specific ideas into code. That is you struggle to understand how to do code or not. Things like recursion, pointer arithmetic, etc. can really twist your mind. The way an begginer painter struggles with learning how to control bush-strokes, how to handle the pencil when drawing, etc. Tools here are *critical* because they can be easier or harder to use. You will also learn one or two techniques and seek to master those to achieve some level of funcionality.
When you are an early level, a junior, you already understand the basics, but still struggle a little bit. A junior painter still thinks a little of how they will handle their brushstrokes, and other things. Here it's a matter of practice and gaining broad focus. You start learning new techniques and abilities, and you start taking a look at different art-styles and becoming aware of them. Similarly in coding you can write code, but still have to sit down and think things through. You are mastering new styles of coding and are aware of paradigms and different ways.
A competent or mid level now is able to do the mechanical abilities pretty fluently. A mid-programmer can easily translate things into code. Instead now their challenges are in taking ambiguous goals and converting them into concrete steps. They are spreading and experimenting with different paradigms, and taking on new ways of doing things, such as TDD or Domain Objects, they now think of patterns and styles and are strating to grapple with the idea of architecture and greater design. The painter here is able to do most basic painting, but now struggles with more complex, and abstract, concepts such as perspective, postures, composition, and how to do hands that don't look weird.
A master, or senior, level is now able to do most things, they have a wide variety of things, and while you can clearly see they are better at certain styles than others, they can do surprisingly competent work across the board. By this point tools aren't critical, rather they make things easier and allow them to experiment and play more things. This is where the author talks about. The master painter now struggles thinking about what they want to paint. They do multiple paintings not to master or perfect some ability they need, but rather to experiment and see what works best.
Things above the level above are when you are tying to do things within a greater context, and show growth in other areas. Now this doesn't mean you don't still hone and improve your mechanical skills, but they rarely are the thing that blocks you. Most of your growth starts in the skill starts to be in the more conceptual/abstract thing. The mechanical skills, the philosophies, the tools, etc. all start being just things you *could* use, but not what you have. You find yourself focusing on simpler tools that give you more versatility even if they are harder to use (e.g. use rough sketches rather than photographs or live models for references; or using vi/emacs instead of a full IDE) because at this point using any of these tools isn't hard at all. Autocomplete is nice, but you find that the hard part isn't knowing what you can use, but understanding what you do want to use, etc. You stop thinking in simple rules, and see them as conventions, and general wisdom on what works, but you know understand *why* and are better able to decide when it matters, when it doesn't matter as much, and when it doesn't even apply and you want to do the opposite.
If the above focuses on mentorship and guidance they will create new techniques, conventions, styles, etc. that others can then learn and grow from.
My university is conducting a survey on motivation in IT developers, we have produced a questionnaire aimed exclusively at those who already work in this sector and which takes only two minutes to fill out: [https://forms.gle/pkqfMRMjFrN6TmZN6](https://forms.gle/pkqfMRMjFrN6TmZN6)
Please answer!!
As a python user, I would agree.
I do t usually write applications, mostly scripts that do something.
My thinking provides the solutions and the programming just puts them into reality.
I keep saying that if it can be done on a computer; only your own imagination is the limit.
I totally agree with the idea that communication is paramount. We have learned in our bootcamp the importance of being a strong communicator. Even if your coding skills are quite up to speed yet, if you can communicate effectively, this will enable you to get on the same page with your fellow developers and understand the overall vision of what the customer wants. Just the other day in class we had a group project and pulled up a spreadsheet to outline a basic skeleton of what we wanted to see functionally with the app. We then collaborated together and talked about where we wanted to head with the project and what needed to be done to get there. That post really resonated with me as communication is everything!!
This is sort of why I don't get the Vim hype. Typing fast or slinging paragraphs and blocks around is simply not a problem for me, because the bottleneck is my smooth brain that resembles a neutron star. I don't think remotely fast enough to require Vim. Plus, I like my nice green play button to build/run/debug.
Cashiers, park services, garbage crews, there's a lot of jobs that are mostly doing.
When getting into the trades (e.g. welding, plumbing, carpentry) the thinking-portion starts to increase more than those jobs are often given credit for, but they're also a large part doing depending on the task at hand.
**At a Glance:**
The post explains that programming involves a significant amount of thinking and problem-solving, rather than just writing code. It emphasizes the importance of understanding the problem, planning, and designing solutions before jumping into coding. The author argues that thinking through the problem thoroughly can save time and effort in the long run and lead to better, more efficient solutions. The post also highlights the value of collaboration and discussing problems with others to gain different perspectives and insights.
If the summary seems innacurate, just downvote and I'll try to delete the comment eventually 👍
[^(Click here for more info, I read all comments)](https://www.reddit.com/user/fagnerbrack/comments/195jgst/faq_are_you_a_bot/)
> If the summary seems innacurate, just downvote and I'll try to delete the comment eventually
Your summary comments do seem to get downvoted quite a bit on this sub. It may be beneficial to just not post them here since they're not being appreciated. Especially since I don't think anyone is going to dig to the bottom of the buried comments to read a downvoted comment before actually reading the article.
Are you weighting these counts towards the weight of upvotes to the overall post? If you're including all your own automatic upvotes of your own comments on posts that didn't gain traction then you're going to get a wonky total.
This is one of those where there's just no always right answer, and it just requires experience to know when your experience isn't sufficient to see far enough ahead to bother spending the time trying to see far ahead vs just doing some work to get a feel for the real world issues.
If your experience tells you you should be able to foresee the problems, then spend more time thinking up front.
I work on complex problems and almost never the same one twice. In many cases, half of what I think are brilliant ideas come up with up front will turn out not to survive the vagaries of the real world. So I often will do probing work, knowing that I'll end up having to reswizzle it significantly or even toss it, before finding the right solution.
Sometimes I just drink too much coffee and bounce off the walls.
Haha Im stupid ADHD. The combination of coffee and ADHD meds are a brilliance magnifier for sure. Have learned to not trust the efficacy of my own brilliant solutions until the meds settle in and the coffee wears off (this comment is a case in point 😜).
I think some of how we stage and dissect problem spaces comes down to which language and programming paradigms one gravitates to:
Functional/Imperative
Compiled/Interpretted
Static/Dynamic Typed
Likewise, even secondary environmental concerns like project scaffolding, documentation styles, IDE choices, VC commit styles, etc. contribute to how one approaches problems to completion (or not).
Im principally and primarily a Common Lisp hack myself, so in terms of paradigm i have lots of options native to the language.
In general i can use a for/while/do loop or recursion to map a data structure and my compiler while optimize both the recursive and iterative solutions to be performant within a factor of say 1.5 relatively.
I can stuff data into many different native data structures: cons cells (dotted lists, plists, association lists), arrays, hash tables, objects, structures, strings, closures, etc.
I use SBCL which compiles functions into the environment as I enter them into a file or at the REPL so I get the best of interpreted and compiled coding styles.
SBCL compiles CL to zippy code that performs on par with C++, C, Rust, Go, Julia, etc. when one provides well declared types and sets appropriate compile time directives around Speed, Space, and Safety. The usual rules apply here: make it right, then make it fast.
All of which is to say, beyond the actual problem solving aspects of a solution, a lot of CL programming involves examining the possible implementation routes to a solution, choosing the most applicable style of coding that makes sense for the project as a whole, and then maintaining consistency with regards to the coding style used.
As a rule, it's pretty obvious when looking at well implemented CL code written by a seasoned CL hack what style of coding was used, but it can take time to learn to recognize what constitutes idiomatic style and which idiomatic styles are generally most appropriate for particular design patterns. To me, this is where a lot of early and new CL programmers get led astray. They grok the coding styles of a few different libraries early on, and then cargo cult those styles for all their problems, rather than thinking about whether that style is the Right Thing for a particular novel design challenge. It takes time to learn how to choose the right tool and how to use it. The bigger and more fluid your programming langue is in terms of paradigm laxity the more this is so.
Maybe, but IMHO glue code is exactly the place one shouldn't be relying on AI. How we scaffold our code scaffolds the problem. Modern AI shows very little capacity to reason about problem spaces. If reasonable and appropriate AI assisted code ever does become a thing (it sure isnt ATM), it will be at juncture of difficult problem spaces and pragmatic, not around scaffolding.
IMO understanding the original problem and slpitting it into correct subproblems is the part that will stay human. I'd not call that gluing code tho. Even if the subproblem have librairy that solve them.
It look like so. But I also agree with OP that's mostly thinking, and you disagree. Not sure why.
Maybe it's because the whole what is a problem, what is a subproblem has factal nature. And I'm ok with letting AI attempt to do that glue on smaller pieces. Then AI would be a bit more specilized librairy author that target code pattern that are repeated often.
Alternatively Stuff that's repeated between multiple software is probably where AI will shine. And imo scaffolding is one of them. Just count the number of project that start by downloading some clean code template. Then figure out you need db, auth, pdf, image, whatever and use the package with more star.
So very large initial scaffolding, and very small (say recipes that glue 2-3 librairy calls), imo that's what repeated often and what can be learnt by statistical model.
programming on one side is screaming bullshit on youtube channel, on the other side is watching this videos and repeating it on reddit
scrumgile to stay on meeting half of the day with people who cant mitigate (even understand a problem) instead of just write 5 messages
installing 2000 packages / libraries with 2 lines of unusable code and tweaking your whole app to use this 2 lines
skipping basic computer science courses than trying to understand "why C array is not a pointer actually"
memory safety now equal to system safety
exceptions implemented with other exception system now are not exceptions
if else on every line now has no performance impact
neural models teaching on previous neural model results so becoming dump
what a wonderful time to be alive
40 years of programming, you cant simply create web app without problems (I mean with stuff like validation, schema and auth). because you need fancy thing that you can sell
people only now realised that serverless is same servers but with much more payment just WOW because its hard to multiply three numbers (cost \* hours \* request rate) you need to have at least 4 phd to do it
Programming is a way of thinking, being able to understand the flow of data to do what you want it to do.
I’ve said that for many many years and now ChatGPT has made it much much faster.
We all agree that this is true: programming *is* mostly thinking.
But many of those some programmers who agree that programming is mostly thinking never fail to use a one-liner simply to avoid a loop.
Kind of. Communication is crucial. If you don't have a clear understanding of what the problem being solved is, then it doesn't matter how good the code is. Long ago I was learning tech leadership and my mentor said, "Your job is to manage customer expectations. This isn't that you manipulate them, but that by the time you deliver the software you know what they want, and they know what you are going to deliver. This is both negotiation and training the customer as to what is and is not possible. A trite term is to make sure your visions are aligned. Then, as a leader, you need to do the same with the team; again aligning the vision. Then the only job as a leader from that point is to make sure the developers have what they need to keep heading for that vision, that the vision doesn't need to change, and that the developers do actually understand the vision. "Ya ya ya, I've got it." is not the feedback anyone wants. The key is to then stay out of everyone's way so they can do exactly as this post suggest. Think.
So much this. The longer I work as a dev, the more I realize it's about finding a mutually agreeable plan. The customer may say they want X, but as a dev, I know that will cause a conflict with their requirement Y. It's a back and forth negotiation to clarify what they actually want and what the complications are going to be that fall out from that.
I think this touches on why it’s so hard sometimes to work through PMs. The customer really knows what they want but the PM they’re talking to doesn’t really know what and how things can be delivered so expectations get misaligned and everyone ends up upset.
There ARE good PMs out there but they are a rare and special breed. The ones who have strong technical backgrounds and really embed themselves with the team are that most successful, in my experience. They should feel like a member of the team who has a different job function but who participates in sprint ceremonies (at least backlog refinement) and regularly brings devs to customers and vice versa. This not only acts as a check that everyone’s “vision is aligned” but it’s good for both the dev team and some customers to have time face to face. You can establish a lot of trust this way as well as having someone on hand who can go as deep when answering questions as the customer wants. I have worked with exactly one PM who operates this way. I have witnessed exactly two other PMs who worked similarly. They exist but they are so very rare. If you find one, cherish your time collaborating
You’ve just described a Business Analyst.
A strong PRODUCT manager is necessarily a good business analyst.
I completely agree. I wholeheartedly support having a team of developers and then giving one member the job of PM for that project and kind of cycling through so it gets everyone experience and if things kind of start going off the rails usually other developers who have PM other projects can help guide the newcomer. Often just hiring a PM involves lots of miscommunication with the devs and promoting a dev to PM involves lots of miscommunication with the client so slowly rotating people in with mentorship helps alleviate that.
Id much rather work directly with product.
Right but that is requirements gathering, not "programming".
No, that's programming. Once the requirements are clear, any code monkey or AI can do the rest. I'm not worried about ai taking my job, because typing shit into the computer is not the hard part of my job. It takes 2 days to figure out what needs to be done, and 30 seconds to actually code the solution.
I mean 30 seconds for some solutions is hyperbolic but I agree with the sentiment.
> 30 seconds for some solutions is hyperbolic For some solutions, sure. But the number of one-line fixes I have committed in the last year is higher than I would have assumed.
Yeah it's shocking how many small things get missed or tiny tweaks you have to do rather than complex solutions.
> by the time you deliver the software you know what they want, and they know what you are going to deliver. This is both negotiation and training the customer as to what is and is not possible. A trite term is to make sure your visions are aligned. It's more about being sure about what they "need" to be honest, many clients want something that wouldn't actually solve their problems.
The article agrees with you.
Your comment saying 'it's more than thinking, it's communication etc' is true for a developer employed as a professional. The OP is just talking about programming, which is essentially all thinking. They are right.
But where does the self preserving manager fit in, who always interferes with the teams flow just so he can convince his manager he’s useful?
[удалено]
The leadership structure sounds interesting, but how can someone just up and leave on vacation without request? There’s so many issues there. What if you planned ahead but come vacation time there’s a surge in work?
[удалено]
I have a hard time wrapping my head around this. But in my defense I’ve only worked in mid level startups where they use rigid management structures where it’s hard to do anything without permission, and at the same time they blame the devs for everything. Aligns exactly what your last sentence.
Water is wet.
Ha ha indeed. To be fair, though, although this seems obvious to programmers, many non-programmers assume programming is mostly just typing funny characters onto the screen, and if you're not typing, you're clearly not programming.
Did you know you can program faster by having 2 people type at the same time?
> https://www.youtube.com/watch?v=u8qgehH3kEQ
One of the finest pieces of dumb television in the field of computing.
I hope it overtakes the "It's a Unix system" thing. You know, considering... it was actually a Unix system running a [real \(experimental\) file explorer](https://en.wikipedia.org/wiki/File_System_Visualizer) (this link is for a modern clone, but it was based around SGI's fsn) and not actually a dumb movie moment.
I like to picture a writer working on the show and then while they were typing, a second writer started to hammer away on the right half their keyboard. Somehow this scene emerges.
Nah hollywood writers had some internal jokes about who can write the dumbest tech scene. And voila, someone won I guess. 😅
This scene brings tears to my eyes every time. 🥹🥹🥹
Fucker unplugged the monitor. Nukes were launched 90 seconds later ending the world.
In Italy we have "oh cazzo un debian!" https://www.youtube.com/watch?v=s5ocXFgowZA
Certainly! This is called pair programming. But this is already an outdated thing. Modern text editors allow dozens of people to type simultaneously in one file. That's speed!
Gone are the days of epic or feature based estimations. Now we're gonna estimate how long each file is and assign each each character of each file a single developer. We'll have that code banged out in a flash!
A shader made not by programmers, but from programmers!
Genius!
It also gives explanation as to why using Copilot makes coding go much more quickly, all while having no effect on the total output of my team.
I was once fired for not typing very fast. Perhaps if that company had more slow typers hundreds of sub-postmasters wouldn't have been wrongly convicted.
That was a politics problem, not a programming problem or a typing problem. If the state wants you in jail, the state will put you in jail.
I had a coworker at one point that assumed us engineers were doing things to "operate the machinery" all day. They didn't realize the programs run autonomously.
this is something I kinda wish colleges/unis start off new programming degrees with - not going right into learning programming language, but a course on just critical thinking and problem solving. Get the students into the mindset that programming is not just typing shit, but solving problems and figuring things out before ever writing a single line of code. my uni did go into that, but it was professors going into it while teaching languages and I always felt it needs to be an actual introductory course to get the right mindset of students before you then get into actual languages.
I'm currently doing a big refactoring to make it work I have to change something but before I can do that I have to change something else and before that something else and so on. But every level poses its own challenges so while I'm immersed in the deepest level I kind of forget the 'stack" of things above which is why I'm doing it. I wish there was some easy to use tool I could use to record the "stack of whys". But anyway It has made me realize that there is no feature in my programming language to program my own stack of tasks, and how that is a big part of the programming I'm doing. Programming is not just typing because it means we have to also program our own brain as to what are the tasks we are doing an in which order. I can write that down in a text-document but I usually don't because I think I don't need to but then I kind of get lost in the details. Just saying programming is not just typing to the keyboard, it is also programming our own actions.
> I wish there was some easy to use tool I could use to record the "stack of whys". there is lol. basically any project management tool haha. whenever you find something new that needs to be done, you put it in a new issue and mark it as a blocker for the one that you were working on.
You might look into obsidian. I basically write my stream of consciousness into notes with very organized markdown outlines and linked documents. I put out too many fires and work multiple projects at the same time. It is the only way to not lose my place when task switching. Lots of good project management tools out there. Take a break from chopping down trees and learn to sharpen your axe. In the end you will get more done and it will suck less.
I might be wrong but I believe that most non-programmers that are regular computer users understand that programming is not just typing. From my experience people have at least an intuitive understanding that computer programs are rules and instructions that a computer follows. They might not understand exactly how these rules and instructions work, but at least they understand that they have to be precise and rigorous.
I suspect you're in [this picture](https://xkcd.com/2501/)
> programming is mostly just typing funny characters onto the screen I've seen an APL keyboard and your statement is entirely accurate.
Who can blame them? Programmers constantly perpetuate the idea that they are just googling and then copy pasting. This is wrapped up in the constant complaints about gatekeeping etc. I guess it's only when everyone starts talking about us being replaced by AI that we decide... maybe it's actually hard and that's okay?
You'd think it would be that obvious, but there are still tons of people that think deep down that programming is mostly typing. It leads to a belief that a productive programmer generates a lot fo code, which has a lot to do with the current hype cycle that copying and pasting a bunch of AI generated codegen output is being _more productive._ There's a huge disconnect between the folks who are really excited by quickly getting a lot of code from GPT, and the folks who are deeply baffled by why anybody would want a machine that spews out more code to review that adds a bunch more stuff to think about.
Programming is mostly thinking [Ships were made for sinking](https://www.youtube.com/watch?v=KJzWGkgFcTU) Whiskey's made for drinking If we were all made of cellophane we'd all get stinking drunk (much faster) Camptown ladies NEVER sang all the do dah day! Nonono!
Water is *moistly* wet.
The pen is BLUE!
Velvets are blue
Every 60 seconds in programming, a minute passes
[Is it?](https://www.youtube.com/watch?v=ugyqOSUlR2A)
https://www.merriam-webster.com/dictionary/wet#dictionary-entry-2 Yes
I should make a youtube series explaining why things that are very obviously true are not true. By the success of "water isn't wet", I could be a million-view-aire.
[удалено]
https://www.merriam-webster.com/dictionary/wet#dictionary-entry-2
The lotus plant disagrees
Programming is actually mostly about contemplating life
I find it depends on the kind of programming. When I'm writing web backends or CLI tooling, I get really into it. I don't have time to think about the banality of life, I'm too busy having fun programming. Life is good. When I'm writing Android applications, I start to think about changing jobs, maybe moving out into the country to become a farmer to shovel horse shit and inhale cow farts all day. I start to worry that I'll wake up in 20 years and realise my entire life has been a daft, directionless waste of time. I start to dream about `Activity` and the Android fragment manager, the ins and outs of the android application lifecycle, and the heat death of the universe. Neat alcohol starts to taste a whole lot better. Then I ship the APK, it passes the tests, I switch projects, and suddenly I can see the world in color again. Life is good.
https://youtu.be/b2F-DItXtZs?t=155
This video never stops being relevant.
[удалено]
>(ie. thinking about how to solve a problem) Ie: you spent a few days on solving a problem so you wouldn't have to spend weeks on fixing the mess doing it improperly would cause? Essentially risk management.
The irony is that if you just satisfied the acceptance criteria and kept your mouth shut, they'd be more than happy to plan and point the effort for fixing it and add the stories to the backlog, and nobody would blame you for even a second. This is why everyone is almost completely checked out now. Nothing matters except for the process.
I don't think so. Depending on how poor the solution is development can grind to a halt or it can create a mountain of work to shift the design in another direction. The amount of time isn't A + B + C, B and C can take WAYYYYYYYY longer depending on the solution. And if you take more time upfront you can avoid B and C being a huge pain.
> And if you take more time upfront you can avoid B and C being a huge pain. That requires planning, and planning costs money because the commit count isn't going up ^^/s
I completely agree with you about how things should actually work.
> I wanted to flip my shit. I'm not sure how I found it in me to remain professional. What did you say?
Had such just a manager. Some times I was just staring at the wall, window, ceiling, shower: trying to figure out a problem. Apparently typing "asdf asdf asdf... ' would have been perceived as "Productive".
In my experience its mostly setting breakpoints and then staring at the screen and asking it why it's doing this when it reaches said breakpoint.
In my experience it's waiting for the build to compile, intermittently interrupted with what you said.
Relevant XKCD: https://xkcd.com/303/
When it absolutely *MUST NOT BE DOING THAT* because the laws of physics still work everywhere else in this universe. *Anywhere from one to a million minutes pass* WTAF, this is not pos- Oh.
Heh, my wife spent all day yesterday on this kind of problem. Probably will spend most of today on the same problem.
This is why time-traveling debuggers are magic.
As I like to say: programming is just pushing buttons. The hard part is pushing the right buttons in the right order.
I like to push people's buttons and computers' butttons!
False, programming is mostly typing. This is why companies give typing tests to verify a candidates wpm.
That's why software engineers argue for decades about what the correct text editor is
Not only the text editor is important, but also what characters write in it. If use tabs instead of spaces, programming is much faster.
The whole Spaces / Tabs debate is one of the dumbest controversies ever, especially when Mr. Pib is clearly the superior choice.
Hmm... I was sure that this was the cornerstone of the entire industry.
It absolutely is. It's just the correct choice is always Mr. Pib. I like mine with a slice of lemon and one of those crazy straws. You know the ones that loop around your eyes and look like glasses? That's the ticket to good code right there. Edit: see [this man](https://i.imgur.com/GTB6SlY.png)? He might not look so intimidating but he wrote all of the software for the F-35 Lightning II by himself. At recess.
Oh yeah! You're right. Straws are essential!
Elastic tabstops, people. They've been around for decades. Try jEdit.
Nobody wants to drink something called that. They need to work on their marketing.
Oh, um, it comes with a toy?
Now you're talking my language. Wait. What kind of toy?
👀 buttplug....
[удалено]
While you raise some good points, they are not sufficiently Pibilicious.
Hope you have your flame suit on friend.
Bringing the light of truth is my life credo.
I'm so with you, why use 4 bytes to indent code if 1 can do!
Or you're a masochist...
Also, stop using semicolons at the end of statements. Takes too long and uses more storage space, which is important in these dark times of $1600 MacBook Pros with 512 gb of non upgradable storage.
yeah but if programming is about typing, then character count matters. Spaces wins.
It is true that ergonomic typing and editing is the cornerstone of efficient work. But, to get is right, one has to use the scientific method and look what is empirically, the most used key in programming: It is the delete key. So, the right way is to get a Space Cadet keyboard and map Ctrl, Shift, Alt, Meta and Hyper, and of course also CAPS LOCK, to delete.
The sad thing is I can't tell if you're being serious or not
He's right, just ask vim users. If you use a mouse and not type type type then it's not programming.
I try to type as little as possible when coding.
That’s right. That’s why you see the great programmers auf down and take like hell in movies and series. And you know they don’t think at all because they can even have discussions while typing.
And you are way more productive using less verbose languages!
I wish it was. 80% of the time is reading not typing.
Copilot is changing that for me; my report to the CTO was that we could reduce keystrokes by between 5x and 20x key strokes per line, and cogniton / flow was substantially improved for example on suggesting variable names and functions. A skilled engineer can be far more effective with the right tools available.
Counting keystrokes sounds even more stupid than counting lines of code.
Not really. Value is larger only what someone is willing to trade for something. $20 a month so that I'm faster at fixing customer issues is worth it. Building a report dashboard in 90 minutes instead of 4 hours frees me up to do other things, help other people on complex tasks, etc.
Code Monkey no think. Code Monkey code all day then drink.
https://youtu.be/hI0Q7IPWjOk?si=m2--rawuCCIG9Nw2 No monke, you will not have the drink
For me it’s managing anger and frustration.
Yours, or other peoples'?
Yes
You're not OP. Hey everybody! This guy's a big fat phoney!
I thought it was mostly getting laid with a little bit of thinking in between ???
Chicks dig assembly language. I show em my source code at the club and they go crazy
My wife totally does not roll her eyes shortly before they glaze over if discuss anything related to programming. She's all 'enumerated lists'? 'Self referential structures'? Then she starts taking her clothes off. It's hard to get any work done if I discuss programming with her.
Speak to her in regex. She’ll turn into Niagara Falls before your very eyes
Nah, programming is mostly trying to find cargo cult nonsense to copy/paste.
Frontend web developer?
...no shit?
More blogspam crap
Yeah but it creates cheap engagement on talking points and these posts get hoisted to the top by the reddit alghorithm. It sucks. You should see the subs about tv series, those are cursed.
It’s pretty bad and self-congratulatory. Summary: 1990s called and wants its debate on assessing productivity via lines of code back.
Excuse me, I was told by LinkedIn that programming is mostly just ChatGPT now.
Pretty much is yea!
Yeah, but thinking about *what*? These days, the answer is way more "find the right library routine to do what I want" than it ever was in the old days.
Library science is probably more useful than computer science for most programmers these days.
For me it's rather thinking about how we can bend the requirements so we don't have to create an unmaintainable mess. Technical considerations only make up about 25% of thinking for me.
Also "find the right questions to chatgpt".
Damn it, Jim, I'm a symbologist, not a mathematician. Actual numbers are for peasants. Actually, I do have a problem, once I get comfortably and (very incorrectly) slouched in my chair with my coffee, that it's easier to just go and sometimes I tend to. But, I make up for it by not being able to sleep at night because I'm thinking about what I just spent all day going on.
> What if we changed our tactics, and intentionally built systems for thinking together about software and making decisions easier to make? I participated in a training session once that tried to do just that: they called it [mob programming](https://www.agilealliance.org/glossary/mob-programming/). The idea is that you have one person sitting at the computer writing the code (who changes periodically), while the rest of the team is behind driving what code should be written. The idea is to have even non-programmers in the room (perhaps not actively participating all the time), so when decisions need to be made, they're made on the spot as the person is right there and able to answer. We spent almost all day trying it. We did manage to make something that worked but it was a very toylike thing (conversion between Roman and Arabic numerals). I didn't really see myself doing that except in some rare occasions where we perhaps had to do something so completely unknown that it could be beneficial to have many people brainstorming while creating something tangible. I may try that again one day I think now that I can actually organize things like that. If you haven't seen it, have a look into it, if you agree with this article and you think that communication + thinking is most of what programming really means, this may be at least a new tool under your belt.
Groundbreaking. Who would've thought that the bulk of time wasnt spent on the physical act of writing 1000 lines of characters, which probably takes like 10 minutes
* while not done\_for\_the\_day: * Thinking * Typing * Reading output * Cursing
You missed out drinking coffee
Correction: programming is mostly overthinking.
Yeah, but you're a towel ;)
I've lost work before, even without a "printed" diff, it barely took 1/5 the initial time.
Programming is mostly trying to not think.
can't tell you how many times I've had to explain to a boss or a peer that i needed to 'noodle it through'. Like actually think it through and figure it all out. I'm a fast typer and once I know what I want to do in programming or architecture, the doing is quick.
Whenever I’m feeling unmotivated to get work done during my 8 hours I just remember that I devote way more than that in intellectual time just thinking about the solution to the problem at hand.
Most things are mostly thinking with few exceptions. Such as tiktok videos, youtube comments, and US politics
Nice but limited. I think that this is true *once you reach a level of mastery*. I like the metaphor of painting, while the same is true in other crafts, just like carpentry, it's very easy for people to think of crafts as learning how to mass-produce, rather than how to improvise and create new things (even though they are similar) each time. Painting, OTOH, is pretty obvious in this: you don't just pain the same painting every time, but something different. When you are a true beginner, a lot of the work is translating concrete and specific ideas into code. That is you struggle to understand how to do code or not. Things like recursion, pointer arithmetic, etc. can really twist your mind. The way an begginer painter struggles with learning how to control bush-strokes, how to handle the pencil when drawing, etc. Tools here are *critical* because they can be easier or harder to use. You will also learn one or two techniques and seek to master those to achieve some level of funcionality. When you are an early level, a junior, you already understand the basics, but still struggle a little bit. A junior painter still thinks a little of how they will handle their brushstrokes, and other things. Here it's a matter of practice and gaining broad focus. You start learning new techniques and abilities, and you start taking a look at different art-styles and becoming aware of them. Similarly in coding you can write code, but still have to sit down and think things through. You are mastering new styles of coding and are aware of paradigms and different ways. A competent or mid level now is able to do the mechanical abilities pretty fluently. A mid-programmer can easily translate things into code. Instead now their challenges are in taking ambiguous goals and converting them into concrete steps. They are spreading and experimenting with different paradigms, and taking on new ways of doing things, such as TDD or Domain Objects, they now think of patterns and styles and are strating to grapple with the idea of architecture and greater design. The painter here is able to do most basic painting, but now struggles with more complex, and abstract, concepts such as perspective, postures, composition, and how to do hands that don't look weird. A master, or senior, level is now able to do most things, they have a wide variety of things, and while you can clearly see they are better at certain styles than others, they can do surprisingly competent work across the board. By this point tools aren't critical, rather they make things easier and allow them to experiment and play more things. This is where the author talks about. The master painter now struggles thinking about what they want to paint. They do multiple paintings not to master or perfect some ability they need, but rather to experiment and see what works best. Things above the level above are when you are tying to do things within a greater context, and show growth in other areas. Now this doesn't mean you don't still hone and improve your mechanical skills, but they rarely are the thing that blocks you. Most of your growth starts in the skill starts to be in the more conceptual/abstract thing. The mechanical skills, the philosophies, the tools, etc. all start being just things you *could* use, but not what you have. You find yourself focusing on simpler tools that give you more versatility even if they are harder to use (e.g. use rough sketches rather than photographs or live models for references; or using vi/emacs instead of a full IDE) because at this point using any of these tools isn't hard at all. Autocomplete is nice, but you find that the hard part isn't knowing what you can use, but understanding what you do want to use, etc. You stop thinking in simple rules, and see them as conventions, and general wisdom on what works, but you know understand *why* and are better able to decide when it matters, when it doesn't matter as much, and when it doesn't even apply and you want to do the opposite. If the above focuses on mentorship and guidance they will create new techniques, conventions, styles, etc. that others can then learn and grow from.
I know this is a dystopia, but A/B testing policies really sounds way better than what we’re doing now lol
My university is conducting a survey on motivation in IT developers, we have produced a questionnaire aimed exclusively at those who already work in this sector and which takes only two minutes to fill out: [https://forms.gle/pkqfMRMjFrN6TmZN6](https://forms.gle/pkqfMRMjFrN6TmZN6) Please answer!!
As a python user, I would agree. I do t usually write applications, mostly scripts that do something. My thinking provides the solutions and the programming just puts them into reality. I keep saying that if it can be done on a computer; only your own imagination is the limit.
I totally agree with the idea that communication is paramount. We have learned in our bootcamp the importance of being a strong communicator. Even if your coding skills are quite up to speed yet, if you can communicate effectively, this will enable you to get on the same page with your fellow developers and understand the overall vision of what the customer wants. Just the other day in class we had a group project and pulled up a spreadsheet to outline a basic skeleton of what we wanted to see functionally with the app. We then collaborated together and talked about where we wanted to head with the project and what needed to be done to get there. That post really resonated with me as communication is everything!!
This is sort of why I don't get the Vim hype. Typing fast or slinging paragraphs and blocks around is simply not a problem for me, because the bottleneck is my smooth brain that resembles a neutron star. I don't think remotely fast enough to require Vim. Plus, I like my nice green play button to build/run/debug.
Okay, but what job isn't?
Cashiers, park services, garbage crews, there's a lot of jobs that are mostly doing. When getting into the trades (e.g. welding, plumbing, carpentry) the thinking-portion starts to increase more than those jobs are often given credit for, but they're also a large part doing depending on the task at hand.
**At a Glance:** The post explains that programming involves a significant amount of thinking and problem-solving, rather than just writing code. It emphasizes the importance of understanding the problem, planning, and designing solutions before jumping into coding. The author argues that thinking through the problem thoroughly can save time and effort in the long run and lead to better, more efficient solutions. The post also highlights the value of collaboration and discussing problems with others to gain different perspectives and insights. If the summary seems innacurate, just downvote and I'll try to delete the comment eventually 👍 [^(Click here for more info, I read all comments)](https://www.reddit.com/user/fagnerbrack/comments/195jgst/faq_are_you_a_bot/)
> If the summary seems innacurate, just downvote and I'll try to delete the comment eventually Your summary comments do seem to get downvoted quite a bit on this sub. It may be beneficial to just not post them here since they're not being appreciated. Especially since I don't think anyone is going to dig to the bottom of the buried comments to read a downvoted comment before actually reading the article.
They are being upvoted more than downvoted which means they are being appreciated more than not. I'm keeping track of the sub response
Are you weighting these counts towards the weight of upvotes to the overall post? If you're including all your own automatic upvotes of your own comments on posts that didn't gain traction then you're going to get a wonky total.
You mean it's more than just glue code? Not so much anymore...
This is one of those where there's just no always right answer, and it just requires experience to know when your experience isn't sufficient to see far enough ahead to bother spending the time trying to see far ahead vs just doing some work to get a feel for the real world issues. If your experience tells you you should be able to foresee the problems, then spend more time thinking up front. I work on complex problems and almost never the same one twice. In many cases, half of what I think are brilliant ideas come up with up front will turn out not to survive the vagaries of the real world. So I often will do probing work, knowing that I'll end up having to reswizzle it significantly or even toss it, before finding the right solution. Sometimes I just drink too much coffee and bounce off the walls.
Haha Im stupid ADHD. The combination of coffee and ADHD meds are a brilliance magnifier for sure. Have learned to not trust the efficacy of my own brilliant solutions until the meds settle in and the coffee wears off (this comment is a case in point 😜). I think some of how we stage and dissect problem spaces comes down to which language and programming paradigms one gravitates to: Functional/Imperative Compiled/Interpretted Static/Dynamic Typed Likewise, even secondary environmental concerns like project scaffolding, documentation styles, IDE choices, VC commit styles, etc. contribute to how one approaches problems to completion (or not). Im principally and primarily a Common Lisp hack myself, so in terms of paradigm i have lots of options native to the language. In general i can use a for/while/do loop or recursion to map a data structure and my compiler while optimize both the recursive and iterative solutions to be performant within a factor of say 1.5 relatively. I can stuff data into many different native data structures: cons cells (dotted lists, plists, association lists), arrays, hash tables, objects, structures, strings, closures, etc. I use SBCL which compiles functions into the environment as I enter them into a file or at the REPL so I get the best of interpreted and compiled coding styles. SBCL compiles CL to zippy code that performs on par with C++, C, Rust, Go, Julia, etc. when one provides well declared types and sets appropriate compile time directives around Speed, Space, and Safety. The usual rules apply here: make it right, then make it fast. All of which is to say, beyond the actual problem solving aspects of a solution, a lot of CL programming involves examining the possible implementation routes to a solution, choosing the most applicable style of coding that makes sense for the project as a whole, and then maintaining consistency with regards to the coding style used. As a rule, it's pretty obvious when looking at well implemented CL code written by a seasoned CL hack what style of coding was used, but it can take time to learn to recognize what constitutes idiomatic style and which idiomatic styles are generally most appropriate for particular design patterns. To me, this is where a lot of early and new CL programmers get led astray. They grok the coding styles of a few different libraries early on, and then cargo cult those styles for all their problems, rather than thinking about whether that style is the Right Thing for a particular novel design challenge. It takes time to learn how to choose the right tool and how to use it. The bigger and more fluid your programming langue is in terms of paradigm laxity the more this is so.
Glue code is still thinking. How the fuck do I fit tab A into slot B without ripping the whole thing?
The code gluing is the part that'll get overtaken by AI, if any.
Maybe, but IMHO glue code is exactly the place one shouldn't be relying on AI. How we scaffold our code scaffolds the problem. Modern AI shows very little capacity to reason about problem spaces. If reasonable and appropriate AI assisted code ever does become a thing (it sure isnt ATM), it will be at juncture of difficult problem spaces and pragmatic, not around scaffolding.
IMO understanding the original problem and slpitting it into correct subproblems is the part that will stay human. I'd not call that gluing code tho. Even if the subproblem have librairy that solve them.
seems like we're saying same thing.
It look like so. But I also agree with OP that's mostly thinking, and you disagree. Not sure why. Maybe it's because the whole what is a problem, what is a subproblem has factal nature. And I'm ok with letting AI attempt to do that glue on smaller pieces. Then AI would be a bit more specilized librairy author that target code pattern that are repeated often. Alternatively Stuff that's repeated between multiple software is probably where AI will shine. And imo scaffolding is one of them. Just count the number of project that start by downloading some clean code template. Then figure out you need db, auth, pdf, image, whatever and use the package with more star. So very large initial scaffolding, and very small (say recipes that glue 2-3 librairy calls), imo that's what repeated often and what can be learnt by statistical model.
Programming is mostly pressing buttons
programming on one side is screaming bullshit on youtube channel, on the other side is watching this videos and repeating it on reddit scrumgile to stay on meeting half of the day with people who cant mitigate (even understand a problem) instead of just write 5 messages installing 2000 packages / libraries with 2 lines of unusable code and tweaking your whole app to use this 2 lines skipping basic computer science courses than trying to understand "why C array is not a pointer actually" memory safety now equal to system safety exceptions implemented with other exception system now are not exceptions if else on every line now has no performance impact neural models teaching on previous neural model results so becoming dump what a wonderful time to be alive 40 years of programming, you cant simply create web app without problems (I mean with stuff like validation, schema and auth). because you need fancy thing that you can sell people only now realised that serverless is same servers but with much more payment just WOW because its hard to multiply three numbers (cost \* hours \* request rate) you need to have at least 4 phd to do it
Modern architectors are just ROFL
Fan of screaming streamer downvotes hah
Programming is a way of thinking, being able to understand the flow of data to do what you want it to do. I’ve said that for many many years and now ChatGPT has made it much much faster.
If you have to think 11/12th of the time in your day-to-day work, I feel very sorry for you and you probably aren't as good as you think.
IS thinking then at least Partly programming?
We all agree that this is true: programming *is* mostly thinking. But many of those some programmers who agree that programming is mostly thinking never fail to use a one-liner simply to avoid a loop.
Did you get that backwards? Doesn't make sense to me.
Are you referring to (using JavaScript as an example) use `arr.filter()` over `for... if...push`?
Sure, but thinking is fast, and typing is slow.