Stop Lying To Yourself As A Software Engineer - From a Meta Staff Engineer

[@faisonx]

0:27 "I'll finish coding this in just five minutes!" 1:14 "It's a feature, not a bug!" 2:50 "I'll remember what this code is doing" 3:47 The myth of multitasking 5:26 "I'll just push this code to production real quick" Very guilty😅

[@pavankumarchaitanya369]

Engineers try to sell these stories to their management to avoid sounding/looking less productive, but they consistently make these mistakes. Most engineers start off risk averse. But they eventually start winging it to become Senior engineers and then slow down to become Staff Engineers. It's a cycle. Engineering leadership should avoid falling for these "beliefs" while planning their projects.

[@foppel]

What I tell my students in terms of documentation: don't tell what you are doing, tell what you intended to do, what the problem was.. the code is (hopefully) self explanatory.. (if not: work on your codewriting skills)

[@primordialsoup-uu5vo]

Wow, I've made so many of these, good to know even someone who can reach staff engineer is able to make them - this helps so much with the imposter syndrome, ty!

[@TimothyJesionowski]

You're missing the meta-mistake: just because you know better in theory doesn't mean you'll do better in practice.

[@foppel]

I do this thing for like.. 28 years? I had multiple instances where I looked at code and went: wow.. whoever wrote this, he really had it down.. he really understood the problem, that is a clever solution.. just to learn it was me. What I want to say the whole 'what I did here or intended to do documentation,' it works both ways!

[@csiwele617]

Thanks for the vid Rahul, very relatable. and it's morbidly assuring to know that I'm not alone.

[@VijayKumar-dn4pz]

The most underrated software dev channel out there.

[@abdullaalmosalami]

To me, one of the traits that distinguishes junior swe from a senior swe is being able to realistically estimate time to accetance of a task. Seniors should be able to do this because they have all their experience to pull from to know how long tasks of X category took them.

[@TransmentalMe]

Yes, 5 minutes... 6 hours later. 😂

[@RahulPandeyrkp]

this is my life story (and why I sleep at 2-3am so frequently)

[@TransmentalMe]

@@RahulPandeyrkp I feel your pain, I crashed out at 2:30 am this morning after working on an Airtable scripting extension project. I was planning to be done by 11 and got rabbit holed into an Async problem for 3 hours 😂

[@wonganikaunda7704]

2 days later😂

[@gorka9020]

I'll see that and up it with an "I'll remember why I wrote that".

[@buddysteve5543]

What about logging code execution processes? That can really help with quickly debugging an issue and resolve it! I've done exactly that at one company who went through many developers with no one being able to resolve the issue until I came along and added a logging system which quickly helped determine exceptions being thrown and all data points not getting committed to the database. I was a star for a little while at that company.

[@itscooldawgdonteventrip]

The only way to go faster from my experience is to have structure and build on what you build previously

[@NosebergEatzbugsVonShekelstein]

So glad I never have to smell other software developers again. Retired last year.

[@markmacw]

As a QA for a decade I have been the QA on the other side of the example you cite for number two. Many times after starting the conversation with the dev I would come to realize that they had the same misgivings and just hadn’t broached the subject with the PO.

[@WildeChelsy]

As I was a new developer I asked a senior, what the code is doing, because there was a bug near this, I wanted to fix. It was a big if-statement with at least 5 boolean, checking some variables 5 classes away. I did not know the whole code base of 1000 classes - I just started the job. His answer was: "(Look at the code) It's standing there" - no commentary, nothing. Later he and the team leader sit next to me and try to figure out, was the code is doing and where the bug is for at least 20 min. We are not writing code for the machine, we write it for humans.

[@mouchy123]

I think you are being unfair to yourself on #4. There are always going to be unexpected behaviors and situations like the notification bar. Its Designer/QA's job to flag it and then the PMs job to decide if it needs to be changed or not.

[@gabrielfono844]

As I am moving on the senior level. I appreciate this video

[@invictuz4803]

Excellent tips, but did he say don't juggle more than three projects at the same time? Juggling more than one is hard enough! I'm glad he said that software engineering is still a new field though given the amount of people worried about AI taking our jobs.

[@default_youtube_profile]

I have a habit of saying its easy to do, then I take 20-30 minute for what I would think will take 5-10 minutes that too when I thinking I speaking generously.

[@dileepkumar-ct2hd]

Can you post a video on how live streaming works from basics or the learning path for video streams in one of your courses

[@hawadrammeh8870]

thanks rahul!

[@mahawewar.dimanthi810]

Very informative . Thank you 🙏

[@hansmortensen5668]

These hold true for Mechanical as well.

[@JohnNguyen-x1w]

Great, honest assessments of SWE....

[@invalidred]

Agree with just about everything said! Guilty of it all!

[@gokukakarot6323]

Well, you didn't need to say I've been working as a SE now, We can see it, barely alive, sulking on failures.

[@ronniereloaded]

We should have podcast involving software engineers and such challenges. Is Mr. Pandey up for the task?

[@itscooldawgdonteventrip]

Eyes bigger than your stomach as a French I smile because that’s an expression we used a lot

[@mojjammil]

Guilty of these continuously We unfortunately the organization wide don't practice adding test plans in PR. We usually push the unit tests in the same PR. Did you ever post a video regarding test plans? Worth making one if there isn't one which is specially relevant from your experience?

[@invictuz4803]

Wait, what's the alternative to pushing unit tests in same PR, and why?

[@thrice5560]

my life is a lie

[@RahulPandeyrkp]

so much lying (to myself) in my career

[@Tinyzkid]

Lying is a sin.

[@RahulPandeyrkp]

and yet it's so common 😅

[@Chad-ug5mb]

​@@RahulPandeyrkp bc when a human learned psychology, sociology, anthropology, and ect. You are a dangerous person in our society.

[@zapxcero]

software engineers worst estimation time ever 😂

[@lawrencejohn1638]

so true

[@prateeknarendra1637]

Nice try for your O1

[@walkerstark9584]

Guilty🙃🙃🙃

[@jiachen1078]

Great video! Thank you! All are good, except writing comment. IMO less comment in the codebase is better, and utilize PR to discuss them? Just my $0.02

[@jangoonim]

ㅎ ㅕ ㄱ ㅏ 잘븐가.... th

[@mirasnussupov7039]

XD )))))))