DEV Community

Cover image for 🧠 How to be a great software engineer without using your brain.

🧠 How to be a great software engineer without using your brain.

Samuel-Zacharie FAURE on April 09, 2024

Edit: Now also available on my blog. I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it. - Bill Gates ...
Collapse
 
samuelfaure profile image
Samuel-Zacharie FAURE

As usual, comments are welcome.

Collapse
 
michaeltharrington profile image
Michael Tharrington

This was an interesting one! Great writing and a good read.

I liked this bit in particular:

I do believe there are merits in the saying: "Sleep when you're very sleepy, eat when you're very hungry". I would add: "Think hard when you really need to think hard".

Haha, well said. That's gonna stick with me.

Collapse
 
rabiulhossen profile image
Rabiul Hossen

Really nice one....

Collapse
 
epigene profile image
Augusts Bautra

"A week of coding can save on 30 minutes of planning" :D
My buddy once said "Writing great code is easy, it's the coming up with it part that's hard".

But seriously, I agree with the need to reducing complexity, I always go back to telling folks that old adage about the human brain only having RAM for like 5 things.

To this end, I think TDD is helpful, even if you have to write a couple of tests that will ultimately be rewritten - it's a way to leave a breadcrumb to return to later without sweating about it too much. It's an unfortunate fact often missed in TDD talk that to write proper specifications, you need to have some code for things to start falling into place. It's an iterative process - stumble about a bit, drop some breadcrumbs, hit on the core behavior and the structure you want for it, specify that, get something working, return to breadcrumbs.

It's a sort of journey from the very detailed out to the most overarching and back again, but now with a clue about what needs to be built, and how.

Collapse
 
fridaycandours profile image
Friday candour

The level of problem you are solving contributes to code complexity. The way you are solving it is is contributed by your level of expertise and your target users, their platform, their adoption, their preferred requirements.

Using your brain is the best part of being an engineer.

Collapse
 
alexbodn profile image
abraham

I cannot agree with you enough ☺️. Thanks a lot for illustrating it.
A reassuring sentence I repeat to my customers is,
"If we can define it, I can create it".
Thus, the burden of hard thinking is shared with the customer, and the expecations won't go wild.
Moreover, I really need to make small commits. Very small. As most of my coding experience is through a textual ssh screen, a unit of commit will usually span just a few file changes, done one by one πŸ˜‰, of course.
And, in the really dangerous field of service management, I constantly oppose changing more than one thing at a time. This, to be hands on when something breaks, and reduce the debt.

Collapse
 
nico_shanstrom_3faa12eb47 profile image
Nico Shanstrom • Edited

I like the links, but that really triggered my ADHD haha. I do feel like the Grug at times from the very, very, bad link thus google searching and found your article. And I totally understand the TDD dilema, AND TDD is awesome, and this is the first time I have seen BDD, which could also be great intertwining the two.

Collapse
 
akostadinov profile image
Aleksandar Kostadinov

One can argue that quick code prototyping is actually a way to build understanding about the task and if necessary to rewrite, that's fine.

Expecially in old projects, they already use existing frameworks for achieving specific objectives. So often I find it necessary to do some exploratory coding before figuring out how exactly something needs to be implemented in a consistent for the project approach. This is especially true with "opinionated" frameworks, where going on your own way is a path covered with tears...

So it depends.

Actually I find it hard when I have to figure out how to change something that 100 other things depend on. More often than not, new features are on the fun side.

Collapse
 
tracygjg profile image
Tracy Gilmore

As a "seasoned" software engineer, my clients expect me for solving their problems by thinking the issues through, not just through coding. Some problems are too complicated for one person to solve through coding alone and need a coordinated response.
Adopting a solution with insufficient thought is only creating problems for later (aka Technical Debt). Whilst this might sound a good strategy for career protection, the reality is your clients will not be impressed.
I suspect it will be those jobs that do not require human brain power that will be most at risk of being replaced by AI.

Collapse
 
alexbodn profile image
abraham

I envy you your clients value your planning. I had to take this by force.

Collapse
 
samuelfaure profile image
Samuel-Zacharie FAURE • Edited

I agree and this is why thinking long and hard at the right time is important.

Collapse
 
murthyug profile image
U G Murthy

Great writeup. I am going start practicing this in dev for today.

My favourite line comes from your post on Atomic Git Commits

you can know what you should do, but you might not know how important it is to actually do it

Thank you

Collapse
 
nicholasbalette profile image
Nicholasbalette

It 's on what one should stay focus and concentrate. Not to drain our mental energy.
Interesting.

Collapse
 
akuoko_konadu profile image
Konadu Akwasi Akuoko

The Prime mentioned πŸ”₯
Let's goooooo πŸ”₯πŸš€

Collapse
 
hlexnc profile image
HlexNC

How did you create the banner:

If you used DALLβ€’E 3 or Midjourney, what prompt did you use?

Collapse
 
samuelfaure profile image
Samuel-Zacharie FAURE

I did not use AI but researched free creative license illustrations.

Collapse
 
bensandeen profile image
BenSandeen

Thank you for not stealing from artists!!!

Collapse
 
mohanavamsi0614 profile image
Mohana Vamsi

wowo