Software Engineering Is About Thinking, Not Typing | Prime Reacts

Recorded live on twitch, GET IN
/ theprimeagen
Reviewed article: jordankaye.dev/posts/thinking...
By: Jordan Kaye
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Kinesis Advantage 360: bit.ly/Prime-Kinesis
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/deeznuts

[@danielpgp941012]

This is very true. I spend 80% of my time thinking about my Neovim config

[@chrishipple4419]

switch to emacs and you can bump that up to 90-95% easy

[@JeremyAndersonBoise]

😂😂😂 both comments 😂😂😂

[@nengforgame8145]

hahahaha

[@thedog5k]

XD

[@thedog5k]

@@chrishipple4419 ECKSDEE

[@cubiccode3867]

I studied Mechanical Engineering and it was all theoretical, a lot of math and calculus classes. There were students who focused on getting good grades and students who just passed their classes, but took part in groups that actually created things (like BAJA, the SAE formula and aerodesign). I can say with certainty that those who actually did things are much better engineers than those who focused on getting good grades (most had to go into academia). The shit is that nobody tells us that engineering is about creating things. And yes, it's really important to think. But it's also important to get your hands dirty and learn how things interact with each other, what works and what doesn't.

[@wbtittle]

This applies to just about everything. Then the system kicks you in the balls. One of the teams at my school designed their offroad challenge racer. The got to the competition. They had tires big enough to handle all conditions. ALL of the other teams had used the smallest tires to get the most speed. But when the track got wet those small diameter tires became worthless. The team that planned for this DID NOT get rewarded for it.

[@calwooten]

true. I learn way more when I get in there and break shit then have to fix it.

[@inevespace]

it is true sometimes, but doesn't work everywhere. You can't sent probe to Pluto using only "hands dirty" approach. Cost of mistakes is high, plus you don't have time to make mistakes. So nowadays it 90% theory, 10% "dirty work". Nuclear weapon is good example. You have to design it without full testing.

[@waikinmak5425]

that's not a good analogy IMO. Both type of people (lets call them "thinker" and "doer") the author described are building real world applications in the industry, i.e. already getting their hands dirty. The author is just arguing for allocating more time on planning.

[@dharins1636]

@@inevespace yes but how many of the "software engineers" really build a spaceship? its always is important to weigh these approaches on what you are building

[@josegabrielgruber]

The article is great, the thing that Prime didn't realize, that's focused for managers, not developers; the article is explaining to managers why engineers aren't always writing code

[@thekwoka4707]

Or how time taken on a task doesn't mean more LOC. Sometimes you write things multiple times and learn how to make it simple and effective. Can end up writing 10x the amount of code that actually is on a PR

[@doodlebroSH]

IMO managers who need this explained to them are not good managers.

[@simonschneider5913]

@@doodlebroSH exactly. because they wouldnt even listen, or just play along while not really giving a rats ass...! :)

[@airkami]

Or they are new

[@ChrisCox-wv7oo]

No matter how much planning, or thinking you do... Someone's got to write and edit those tens / hundreds of thousands of lines of code.

[@SiisKolkytEuroo]

And that's why they'd better be well thought out. As someone's got to maintain them

[@TheBswan]

Yep. I committed ~5000 lines last week. Lots of thinking, lots of typing

[@tacocrunchies]

Right but you probably could have done that in half the lines with proper planning and not a shitload of ductaped solutions.

[@austinhutchen]

@@tacocrunchiesvery true

[@zebraforceone]

@@TheBswan If you are doing that week in week out, and can't abstract or DRY that down to less lines, have you considered automating source generation?

[@aidanbrumsickle]

Thinking before you code is only as useful as the accuracy of your mental models, and you gain clarity only through experience coding. I can't count the number of times I've tried to a priori determine a good abstraction only to realize that there was a dimension of coupling that I had not taken into account and now I was obscuring that in order to preserve the illusion that the shape of my design was the true shape of the problem. Now that I have a lot of experience, I can trust my gut more. But I always thought I could trust my gut.

[@Ziggity]

This is why I found the whole notion of LLMs replacing software engineers to be kinda silly. A software engineer's goal is to solve problems, not coding. Heck, as much as I enjoy coding, I'd rather solve a problem at work without it if I could help it.

[@AmonAsgaroth]

The thing is LLMs are much better at abstract creative problem solving than actually coding / doing stuff. So it's easy to ask it about high level problems and maybe some code samples but you have to stitch and adjust it manually. I hate it but it does automate the creative process while leaving menial labor for humans. Ironic, because people used to imagine it will be the other way around. Artists were supposed to be the last to automate and currently they are the first victims...

[@rockdude1122]

from my use of gpt4 i found it is much worse at coding than explaining/creating ideas. it makes tons of mistakes while coding but can break down really hard problems and suggest/brainstorm good solutions for almost anything.

[@bernardcrnkovic3769]

@@AmonAsgaroth i've heard this line 100s of times since gpt launched. not buying it. it understands nothing that deviates even slightly from learned happy path.

[@vitalyl1327]

LLMs can solve problems far better than the vast majority of humans already.

[@user-od3ii6bd7d]

@@vitalyl1327I highly doubt you can substantiate that claim

[@chewbaccarampage]

The amount of planning/thinking is proportional to the consequences of failure. I worked on firmware code for a surgical tool and we had to plan out the code for several months to figure out how we could prevent bugs that could kill the patient. However, working on a simple accounting app, we basically planned for a day to figure out how we could prevent losing money for a customer. We can see what happens when a code first approach is taken in the wrong context - Boeing 737. They tried to use software to solve a physics problem. It was stupid - but people just got to coding it.

[@MachineYearning]

Different people do software engineering different ways. Some people are better reasoning about things in the abstract. Others need to feel out the shapes of systems in practice. The real challenge is, can you leverage both of these types of thinkers to improve your engineering product, or will you be limited by forcing everyone into a single way of how things "should" be done?

[@victorcadillogutierrez7282]

Everything is about thinking, even a writing a book is about thinking; not writing; building a house is about thinking; not building. You need to think first about what you wanna do and then do it, there's is no interface to send our toughts and conver it to code, a house or whatever automatically, and there's alot of the language and frameworks one need to know to deliver a solution. Every profesional needs to think first and master their tool to deliver that solution, for software engineers is code. Language is a tool we humans had made to communicate abstract ideas, and the more clean you write those ideas the better others can understand you.

[@Mark73]

That paragraph that started with "One approach I like to use ..." I understood it just fine. It makes perfect sense to me and is what I generally do.

[@tinrab]

True. That's why I heavily dislike people who complain about static types, memory management, borrowing rules etc. A few extra key strokes is nothing compared to time and mental cost of fixing nonsensical problems.

[@MrAverageViewer]

Exactly!! It's why many love TypeScript and Rust, and the problems they address.

[@majorhumbert676]

These are lazy programmers. At least the ones that I work with who do this.

[@arrux4822]

It's just lack of experience

[@101Mant]

It always amazes me the computer programmers of all people want to waste human time on problems that can be automated. I remember talking to someone complaining about why people keep adding typing like type script and type annotations onto dynamic languages. Probably because they were fed up spending hours chasing down a bug a static analyser could find in seconds or a modern editor could highlight as you typed it. Who has time to waste on that.

[@Tobsson]

​@@101Mantand then you add React to the project to keep those non sensicle bugs around.

[@doresearchstopwhining]

Looks like prime is still trying to wrap his head around monads with in his gpt history - "Monad Explained with Burritos" and "Burrito Analogy Explains Monad"... Monads....

[@godeketime]

I always find the "either/or" mindset around doing/thinking bizarre, when "planning" can be as quick as 15 minutes. When confronted with a new problem, I often make a quick mind map and then use that to create a rough work breakdown structure. That lets me identify the critical path, which can then be attacked in code to further understanding. From that point, both the mind map and work breakdown structure can be discarded: their purpose was to guide to the critical path and get a minimum viable product structured enough to get v0.2 value out of the v0.1 attempt.

[@airkami]

I love meetings where we also work on what we talk about

[@ANONAAAAAAAAA]

Software engineering is like: - Consulting PMs for 40% - Reading codes and discussing with other engineers for 30% - Writing codes for 5% - Testing including writing test codes for 15%

[@AnthonyBullard]

Prime is a coding “Pantser “ as they say in writing, as opposed to a Planner. I think different people work effectively in these two modes, but the Planner mode is better when working on larger teams and across longer time spans (even if I am a Pantser when I POC)

[@JakeDuthDev]

Prime works at netflix, btw

[@x--.]

Isn't this what he's getting at, that his favorite method of exploring the problem and planning for how he is going to solve it is by writing experiments?

[@JeremyAndersonBoise]

I think this is one of the more insightful comments I’ve seen in a while, thank you

[@JeremyAndersonBoise]

For my part, when I am desgning a a greenfield or MVP product, or a major refactoring I am a “planner.” For a POC and/or shit’s-on-fire debugging I do well as a “pantser,” by the majority of available evidence. I like to think through the design of the relational data schema minimally but carefully, especially when building something new. Hate it or not, that’s what I do for anything of significant size that I am considering. Awareness of your present context within the process is the key to knowing when to switch it up. Having both modes of work, (fast thinking vs slow thinking) available to oneself is a boon, in my opinion.

[@whatever7338]

@@JakeDuthDev He does but they have architects there that do these plans before he touches anything. Also there are million different applications out there, some of them cant stop working or must have very tight security and etc. These types of apps have a lot of planning and thinking before any developer touches the code.

[@awesomedavid2012]

Before I watch, the two aren't mutually exclusive. That's why we had to write essays in English class, for example. Writing (literature and code) is an extension of thinking just like talking is.

[@JeremyAndersonBoise]

Nailed it, good play!

[@Kane0123]

Let him cook

[@peerreynders1824]

Hammock Driven Development (2012) by Rich Hickey covers thinking before coding a lot better.

[@d7ffab979]

I recently reduced the size of one of my repos by over 90% from 40k lines of code to 3k lines of code, by just stopping, rethinking the architecture for a month on just paper and then executing on that. That being said, this is only possible in hindsight. I could not have come up with this architecture when I started coding the repo, because I was not fully aware yet of all the things I would run into.

[@PetrGladkikh]

This is one of articles I support completely. That dude-in-the-corner can ask or re-read if he does not get something.

[@za7304]

Yeah even in school they are teaching me this

[@gjermundification]

I always considered myself a philosopher, and sometimes I invoice the time spent while dreaming, front loading is my key skill; Thinking about a task before I go to bed, then dream the solution while sleeping, this way I can type it in during my morning session in vim. Usually CE[S]T 03:00 - 06:00

[@7th_CAV_Trooper]

I think Prime's philosophy is go get your hands dirty and learn something, repeat. I agree with that idea, but I can explore the problem domain to some degree without writing code.

[@complexity5545]

That is always the creative way. Then you go back and make edits if the program or English Paper is fruitful. (or the musical song that you just free-styled, or that riff you were Canon practicing and somehow it turns into a different sounding hook). Just get started.

[@mrdrsir3781]

I don’t really view these things as separate. You think about the problem and plan out for you bit to give yourself direction and then you build part of it and that lets you explore and cognitively offload part of the problem. Then you plan out a little more with the freed up brain space and new problems you might have discovered, and rinse and repeat. It also depends on the size of the project. If you’re building small tools the planning might just be a few minutes entirely in your head. If it’s a large service with many interconnected parts you’ll have to plan more, make diagrams, make sure you understand what your goals are quite clearly. And you’re planning stage should always be a fraction of the time you’re coding. Planing the specifics of each function is basically the same as coding it without getting any actual work done.

[@marcusrehn6915]

It is about thinking, and also about typing. The better you type the less frustrated you will be. The less frustrated, the more productive.

[@chewbaccarampage]

Just watched the talk "Designing for Programmer Delight by Richard Feldman". He describes the tradeoff of quick design. His summary of things that he considers from thinking and design. This can take as little as 15 minutes to 1 hour to answer. 1. Usefulness - does this cover the use case? 2. Convenience - are advance use cases painful? 3. Performance - if the solution is slow, can it be fixed? 4. Error-Proneness - is the solution full of footguns? 5. Upgradability - will common improvements cause breaking changes? I've experienced so many times on projects where the team charges in with code without even considering "Usefulness". Then shipping a feature that nobody uses. However, if none of these things are a risk, then quick design might be worth the tradeoff.

[@poorpotato4467]

Construction is about Writing Blueprints, Not Building

[@chupasaurus]

Had a good laughter about decomposing vs making MVP and growing from there with devcontainers as an example, it's exactly why Docker Inc. abandoned *everything* except image format and their old API is translated to lower level one just to keep backward compatibility.

[@ParadoXxGER]

“Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” Abraham Lincoln

[@aigonewrong.]

4:52 "everyone shut up and don't mention it" 🤣🤣🤣

[@michaellatta]

Planning is invaluable, plans are worthless. Planning can allow us to identify the components and most importantly the known risk areas. Then proceed and resolve the risks and revise the plan at each step. A recent project goals were heavily modified when presented to other leaders in our company, to allow value sooner along the way to the final goal.

[@programaths]

To give a practical example, I did a project for advanced form validation with configuration provided by the user. I need to have literal values, computed values, and fields at some point. The whole implementation has no clue about the fields themselves or where the value comes from. It just asks something else: what is the value of field X? What is the value linked to some variable Y ? Later, another dev had to implement the same feature in another technology. It was a copy-paste, and all he had to rewrite was the part answering the two questions above. It was so unfathomable to him that he didn't even understand that it was all he needed to do. It was so strong that I had to ask him to take control, do the copy-paste, and write a few lines of code with him...then it just worked. The other nicety is that testing was much more straightforward. The core worked, so only the pluggable part had to be tested for his specific project, which was as easy as reading the code to confirm it did what it should. And yes, it looks weird to have a class that required a FieldLocator and ValueLocator, but that made it easy to port. It also makes the core more high-level and reusable. You don't have to read some documentation to have an outline of the algorithm; the class is so short you can read it at a glance. It's the kind of code a junior would refactor to "reduce complexity" or "flatten the object graph." 😂 And I saw that at play. I wrote a set of decorator classes in one company to implement different concerns. There were like 5 types involved, and it looked like this: new A(new B(new C())) I quit, and someone wrote that by merging the content of each class. The company asked me if I could give them a hand because it hadn't worked since the rewrite. Yeah, that's why it was done the way it was done. To ease adding and removing features without confusing oneself passing a train of booleans to the method ^^ It is also much faster in a test; you can just initialize your service, omitting one decorator (the one making requests to a third party for legal reasons). "It's over-engineered" or "It's written academically" is a cope for "Albeit it looks simple, I am uncomfortable with it, so I will rewrite everything, and it will be bristle."

[@jonnyso1]

Planing ahead only to find out you can't predict the future, that you don't know everything you needed to know before hand to make a decision, is also a thing. In the end you'll only find out as you're executing, unless its a domain and tools that you know inside out.

[@human-ft3wk]

I fall into the camp of the writer of this article. But idk if my approach is better than someone who starts typing straight away. I always open up a notepad and jot down my general thinking of how to solve the problem and break it down into modules. But it literally takes me 10 minutes to come up with a rough plan and then I start coding away. I find that by doing that first I get my coding done faster and I stay on track better.

[@noriller]

From the title alone, what I would say is that it's not about the coding part. Yes, anyone can build. A senior can come up with a few possible ways to do and iterate quickly from there. It's not about that. More times than I would like to, I saw people jumping into coding when they could just had stopped a moment and asked the client: "why?" Sometimes the answer is not code. Sometimes the answer is something else. More times than not, just because "they want" won't solve their problem. Only after you do the dirty and easy work of... typing.

[@TheSoulCrisis]

There is an inverse relationship at play between thinking and implementing solutions. The more thinking and refining of the solution before implementation, the smoother the implementation will go and so will the maintenance of the product thereafter. In the real world you need just the right amount of thinking to get the job done effectively and efficiently, but a lack of thinking will lead to inferior and buggy products that are a PITA to maintain later (plus severe code bloat). I bet the 80/20 principle could be applied really well here too.

[@wbtittle]

Making things break... IMPORTANT. Thinking about how you done fucked up in breaking things IS also important. I can't tell you how many times sitting in the shower debating whether or not I am a human, that my brain changed it viewpoint location and suddenly the clouds parted and I FOUND another problem to make me curl up in the corner in my braining crying over what the previous programmers had done...

[@wbtittle]

Ctrl-C Ctrl-V --> OMG I hate these two things. Ctrl-c Ctrl-V --> FM, I just did it again, I played with your heart, got lost in the game... Baby baby...

[@Th3_J0ker22]

Tom is a genius, he doesn't need to think. Just code it Tom!

[@sheykenasababy]

It needs to be a balanced relationship between writing the code and mentally engineering the solution you're writing. That's why idealistic lead engineers who choose elegance over pragmatism but never touch the code wreak havoc on productivity. There comes a point where you have to stop your solo whiteboard masturbation and experience the tediousness of your cognitive ejaculation.

[@vincentyou7994]

😂well said

[@Exilum]

The XY problem, I'll remember. I don't know what to feel about the article. Sometimes it's not about thinking deeply, it's about thinking the right amount. You don't always want to overcomplicate things. I remember wanting to do X, decomposing it into A, B and C, and spending a lot of time figuring out each step, when there were relatively easy solutions to wider problems that could encompass A and a part of B, or B and a part of C. Flexibility in thinking is essential if you're going to divide things up into parts, even if it's to think about them. Also, I don't think I ever stuck to what I wrote down before starting a project. Some things end up being easier, some thing end up being unnecessary, and new necessities show up in unexpected places.

[@snorman1911]

IMO the reason for thinking first is to avoid overcomplicating it. It's a puzzle to solve as simply as possible. Sometimes diving into the code without thinking it through ends up requiring some gymnastics to make everything cohesive. If it's a POC though sometimes getting to code faster is better cause you learn from it, and you're gonna throw away the code anyway!

[@Exilum]

@@snorman1911 You can overthink by thinking first too. That's why my first go is to code an outline, even if it's thrown out later. I don't think there's any issue with laying out a problem on paper first though, I just prefer to think in terms of code. My main issue is when people try to think everything down to the smallest element before even having a go at the problem.

[@t769jo]

Windows key (open start menu) => type: "change system sounds" => Sound Scheme: No Sounds

[@user-br5fz3si8b]

If you are here, you are the kind of dev I need in my dev team. Looking right now for TS and Python devs that have in their core the Prime ideas. Long live vim chads.

[@arjix8738]

Nice recruiting idea ngl

[@MikePaixao]

My process these days has been to simply imagine the end goal, then reverse engineer my imagination. This way you start with the solution, and take the time learn what you need along the way 😃

[@Dogo.R]

16:29 is basicly "I want to hear more about stuff I feel I could put up a strong defence against... I dont want to hear about stuff I dont really understand and cant really comment on or defend against". Not trying to be snarky but that kinda is the reality of the end conclusion he had. He didnt comment on what was said in the artical because he didnt really get it, and in the exact same way he said the article didnt really comment on what he cares about. Its just two people talking past each other.

[@pif5023]

You can see that as a different engagement with the problem: some people like approaching behaviorally other cognitively. I think is more a different style. I do agree that the thinking style is prone to over engineering but the same way the behavioral style is prone to subpar code. I don’t think one is better then the other. In the end you need an healthy mix of both regardless where you start from.

[@simonschneider5913]

the most cruel application of the XY-disaster is in medicine and psychology! because they rarely even follow the script(13:58) halfway through before one of the contestants checks out and just does whatever he wants. usually the one that thinks he is smarter but has just not yet pierced through their own ignorance.

[@brandonpearman9218]

I think it depends on the software. There are some projects that are in serious poor shape, and its super easy to just break everything with one harmless looking line of code. These normally take ages of thinking, reading, debugging, planning to just write one line of code. I imagine people working on this all the time will be strong advocates for thinking. Where people that do more greenfield projects will be advocates for typing.

[@kelton5020]

I think the entire point about being able to better explain the software from a high level is pretty fair. You do yourself a disservice, not trying to improve that process, and instead suggest that managers/leaders need to change. Those are the people who pay you, and the smoother that experience goes the better.

[@DMSBrian24]

Some planning is ok but the things he described? We just do that shit on the fly and polish it out in the end if needed (more often than not, it's not needed)

[@DMSBrian24]

Just like Prime said, build an mvp and iterate from there based on requirements

[@briankarcher8338]

I've been at a place that did performance metrics based on number of commits per day among other metrics. As if all software development is created equal. They wanted 2-3 commits per day. I was like "Sure, if you are just bug fixing, I can change a button's color 10 times per day!". But if you're developing a new system from the ground up? Not as easy as those one liners. Not all code is created equal. Not all situations are equal. Not all problems are equal. But they didn't care. They just wanted a metric to fire their best developers - the people actually creating cool new products and keep the support staff. Edit - Pluralsight Flow sucks.

[@MrSquishles]

You should lower the typing friction in your setup and editor anyway. Because you know what's going to throw your thinking, having to wait as you edit shit or dealing with an awkward editing process.

[@rewrose2838]

I genuinely got weirded out and confused when I heard that Windows sound, because I hadn't heard it in a long time and didn't have any clue where it came from lol

[@georgehelyar]

In my experience software engineering is about having excessive meetings

[@leonardotavaresbrown9779]

the guy sounds like someone that would write 2 pages of documentation when just a properly named variable would be enough

[@mage3690]

The "X Y problem" is why I say "the customer is always right, but the consumer also never knows what they want." Yes, thing bad. Why thing bad? Thing not do what I want. What do I want to do? The wrong thing. I make thing do wrong thing, I learn nothing (or worse), and now the thing is worse for it. "Listen to your costumers but take no advice," is what I say you should do instead.

[@samhughes1747]

also, typing time is a constant cost on trying the ideas you thought of. If you can type fast, you can do your precious thinking faster! Nothing is lamer than being on a call and waiting for a woodpecker typer to finish the 10 lines of code you have now angrily typed and erased at least twice.

[@thekwoka4707]

I generally try to focus on longer term systemic solutions to problems. But some things also dont make much sense to do there...

[@aakarshan4644]

I thought the article derailed but it didn't. The point about commit history and superficial Y work which beats around the bush X is a major problem which has to be dealt with thinking more so than typing.

[@ever-modern]

The Name - is the WinAgen!

[@ErazerPT]

Not even sure why this has to be either/or. That's just a bad mindset. You can just as much think about the problem a lot and then write code that the system reality turns into trash as you can cowboy code your MVP and get stuck in refactoring hell down the road. I always find it more useful to think a bit about things, write some PARTIAL solution, update the thinking part with what i discovered along the way to check if it still makes sense, write some more, repeat. A bit like doing the design, the code and the documentation all in sync. No time wasted, when it's done, ALL is done. Loved the XY Problem part too. Didn't know it was formalized, but experience it a lot when people come and i tell them "ok, you told me what you are trying to do, now tell me what problem are you trying to solve". And suddenly they realize they didn't even think all that much about what problem they were trying to solve.

[@andyk2181]

If you're good at typing it'll reduce your cognitive load and you have more capacity for thinking about the problem. It might not be a huge gain, but learning to type is fairly straightforward.

[@ThePrimeTimeagen]

its straight forward with literally no downside

[@joshuatye1027]

@@ThePrimeTimeagenexcept when someone has sour grapes about a low wpm and a sluggish workflow

[@cubbucca]

13:00 Geyser "10x your software engineering"

[@abc123evoturbobonker]

20 seconds in, Prime is scared, all I see is 1-69-8 words, this is gonna be gooood

[@pif5023]

I have one thing to say though, if you are an engineer that likes to do the thinking you can get screwed over real fast with modern metrics as people who like to do the typing are very happy to use your ideas. Also the people who do the typing first they will present a PR while you show up with just a proposal. Food for though.

[@magne6049]

Effectiveness > efficiency ! Being the fastest in the world at solving slightly the wrong problem is ‘achieving failure’. The most efficient work is no work. The best code is the one you didn’t write. It has no bugs and no maintenance cost. Deleting code is also a bliss.

[@fuseblower8128]

As a C++ programmer I don't have to type at all! I simply dream the code into existence. It's all virtual anyway 😁

[@chinmay8954]

GigaChad

[@complexity5545]

Neo?

[@germantoenglish898]

"Chatgippity Chatgippity Chatgippity Charoot" (Mary Popups)

[@FaZekiller-qe3uf]

Software Engineering is about engineering software, and I don't mean that it's about software for engineering: It's about software engineering.

[@taklamak]

It reads like an LLM hallucination. It just structures stuff repeats it.

[@steveh7922]

Just code the little stuff, plan like crazy for the big stuff and everything else is in between...

[@TheZetsubo]

I snozed on a snail

[@TsoiIzAlive]

Jarred who pushed node modules comment made me weak 😂😂

[@brijeshamin]

I just started trying to improve my typing speed and here it is...

[@daedalus5070]

Took me while to realise that the typing part is what I dislike most... having to remember all the magic words and syntax can be genuinely irritating when you know what you are trying to do.

[@martonkardos8094]

This is like telling the same to a writer. Like how the fuck are you supposed think if you can't write your thoughts out of you, it's ridiculous

[@luciusoflegend]

Can we get a new Primeagen meme: "GO XY URSELF"

[@dharins1636]

To me, start small, start experimenting, yes with your code, get your ideas as bad code out, then once you get to know minor details (that usually only happens when you actually get to execution), the managers mostly dont know shit about the codebase nor engineering most of the times. That way because of those details you have already encountered, you can now plan ahead, and the estimation would be more accurate. All plan and no game is what is causing so many startups to fail, even small projects and startups in Google

[@dharins1636]

Btw i mean for non-architecting things, writing software and build system do require different approaches.

[@returncode0000]

This guy is probably a software architect and refer to the concept of the 12-factor-app at some points.

[@kahnfatman]

Typing like with fingers or Object classifications?

[@ShadoFXPerino]

My favorite text editor is sed/awk

[@MalushJ]

the contribution point is not really fair, it also tracks a lot of generated code that you don't write.. just pointing it out

[@rsfllw]

what a painful article, thanks for the video!

[@iCrimzon]

Thinking is about writing, not thinking

[@brucen83]

Evolves as you actually do the work. The plan I mean.

[@conorx3]

The answer is always write more better code

[@ttcc5273]

Asking questions before you understand the problem space seems ok to me... i.e. an attempt to understand the problem space, no?

[@noahg2]

Bruh this is probably the only white collar profession where someone writes an article every week like "what is a software engineer", "what makes someone a good software engineer", "how to be a bad software engineer", "what is software engineering all about" despite working as a software engineer for 10+ years. I don't see lawyers, doctors, surgeons or university teachers doing stuff like this, probably why AI might replace us in the first place 💀💀

[@SiisKolkytEuroo]

That's true. Software engineering is just such an incredibly young field. Doctors used to be like this a couple hundred years ago

[@x--.]

I can't speak for doctors or surgeons but there is certainly plenty of navel gazing in law and university. Though less so by professors who know the best professor is the one who brings in money, causes no controversy and is willing to spew whatever BS the administration needs.

[@noahg2]

@@SiisKolkytEuroo Not really, it's just that people have strong opinions and like to overcomplicate simple stuff.

[@MrFram]

Because programming is the only job you listed that also happens to be a subculture and a hobby (you could even call it a fandom). Plus there's a huge bias in internet-writing in that software people are more likely to write blogposts in the first place, both for cultural and technical reasons (because they are more able to make websites (duh), to practice maintaining a website as a resume booster...). Most people nowadays are stuck on the same handful of websites (youtube, twitter, instagram, reddit, etc) and the communication formats they normalized (videos, tweets, photos), and tech people are among the few who dare to try anything else at all (e.g. prior to the xitter fiasco, Mastadon was populated almost exclusively by programmers and tech people, since nobody else at all would ever try a "federated social network", even suggesting such a thing would evoke a disgust reaction in normies, them thinking it must be some сrурtо-thing since it's "decеntrаlizеd"). Then of course a disproportionate amount of blog-posting would be done by programmers

[@jonse5a]

Break your big problem down into smaller problems, but don't XY.

[@annaczgli2983]

You know it's so weird & funny to see the amount of pontification in this field. "Software engineering is really this not that"; "You really should be doing this not that"; "It really means this not that." As I grew older I realised people in this field are very opinionated, & that I can freely ignore most advice, sans detriment.

[@OverWilliam]

This author is obviously very young

[@CaptainWumbo]

The answer to why people think this is that they are working in a dev environment where every command takes minutes to hours to execute and the benefits of being able to write code and execute commands quickly evaporate. Programmers who write code very quickly are sensitive to shitty dev environments and take the time needed to keep them healthy and fast. Devs who take 20 seconds to move their mouse to the terminal section of their ide and type out their test command are not going to be as sensitive to that test taking 20 seconds to start up and anothet 15 to actually run. I think devs who are very good at writing and running code get thrown under the bus by colleagues that do not think about the health of the dev env. And eventually it gets so bad everyone is forced to waterfall every task because running the code is prohibitively expensive to do more than a handful of times.

[@IgorGuerrero]

Maybe if you take a step back, read some documentation and THINK a little bit without typing so much, you'll finally understand Monads :D

[@andyk2181]

Don't you have to live in the mountains for 10 years practising zen before being awakened to Monadism?

[@IgorGuerrero]

@@andyk2181 Nope, it's a simple concept if you think and not type like monkey (Prime style)

[@ilearncode7365]

In the future, they will hire people who’s job is to think and draw out the pseudo-code, who then outsources it to an Indian code monkey to implement for $1.25 a day

[@andyk2181]

Everytime I've been at a company that did that, someone in-house would end up rewriting the entire thing.

[@dext0rb]

this thought process is so tedious

[@justbobinaround7279]

let some_string: String = 42; Grug no think, only strong-type

[@jordixboy]

This is how you get bloated companies. 10 "thinkers" and 1 doer. SE is about thinking and writing code, end of story.

[@biomorphic]

You confused MVP with PoC. What you want to build is a prototype, a Proof of Concept. The MVP is a product with the most valuable functionalities, it is the first version of your product, a product that is good enough to be sold.

[@101Mant]

Although once you have a poc sales sell it and it becomes the MVP.

[@AutoVideanSpiral]

If you're bad at thinking it can be about typing

[@Tony-dp1rl]

As developers, we are writing way too much code for things that should be data-driven or reused. Particularly with AI now making it even easier to pump out code that would be redundant in a well-designed system. Development has become just like the pumping out of repetitive cheap romance novels.

[@pif5023]

I am pretty sure Prime hates Java because Vim it’s not an optimal editor for it

[@TheHackysack]

0:30 breast practices?! lol

[@Dominik-K]

I 100% agree with it being shut typing and thinking... And debugging, testing and the rest as well. Depending on the task, those will just vary in effort and time allocated to them