DEV Community

Cover image for Best tweet-sized programming career lessons
Tomasz Łakomy
Tomasz Łakomy

Posted on • Updated on

Best tweet-sized programming career lessons

Before we start - I'm working on, a brand new way of monitoring serverless apps 🚀. Check it our if you're tired of switching between 50 CloudWatch tabs when debugging a production incident.

A short while ago I've tweeted a following question:

What’s the best tweet sized lesson you’ve learned in your programming career?

Quite a few of developers from various background decided to share their lessons learned in the Twitter thread and I'd like to share some of them with the community

1) "Experience comes with time and practice" - Ania

2) "There is no magic happening in the programming world" - Xiaoru Li

3) "When things go wrong, blame the process, not people." - Sophie

4) "Manually verify things you’re very sure to be true" - Jamon

5) "Software is not the goal, it is the by-product" (I absolutely love this one by the way) - Adri

6) How do I set a breakpoint with JavaScript - Tobi

7) "Make your worst-case estimation for the time you need to solve the problem, double it, and you'll have a realistic timeline." - Olena

8) "Always back up your database. Always verify that your backups work." - Harper

9) "“When you became master in one thing, it’s time to become a student in another”" - Marc

10) "Solve problems. Learn in public. Be a +10% engineer." - Piotr

If you're on Twitter, I highly recommend you follow all of those amazing people.

By the way, what are your lessons learned in your career?

Discussion (6)

tobiobeck profile image
Tobi Obeck

Hey Tomasz, thanks for the mention. 😃 That was a cool tweet idea of yours that collected a lot of great wisdom! 🙏

I would like to give another few hot tips 🔥:

1. Divide and Conquer

Divide a problem into sub-problems. Reducing the area that affects the problem is oftentimes enough to see the solution. Find the most simple version that proves your assumptions right or wrong. It's a bit like recursion. Make the problem tinier until there is nothing to remove.

These problem-solving skills are crucial as a developer and can be transferred to different domains, like fixing a drain, a printer or your parent's audio equipment that has been so quiet lately.

If that still doesn't help, build a minimal example of what reproduces the problem (MRP). Just imagine doing it for a third-party reviewer on StackOverflow who doesn't know what your project is about #rubberduckdebugging. This should highlight the actual crux of the problem. If no insight is apparent, you have likely a lack of background knowledge. At this point, it is time to read up on related topics. As a last resort, the minimal reproducible example can be used to actually post a StackOverflow question or ask in forums.

2. Searching Is a Skill

Knowing what to search for. Knowing the exact keywords to throw into a search engine is one of the best skills to have. I oftentimes find myself searching a given problem, opening a few tabs, skimming the tabs, realizing they solve a slightly different problem. Therefore, adjusting my search terms, adding new or replacing some of them, opening another few tabs, until I find what I need. You don't have to know everything, but you should know where to find the needed information. Be it Google, StackOverflow, a documentation, a book, colleague or friend.

3. Improve your English

For me as a German, I always have the feeling that resources for learning or documentations in English are much better than German equivalents. Sometimes there isn't even a German documentation (e. g. Vue.js). The choice of resources is also bigger and more varied. Nowadays, I don't use German keywords for searches anymore. This started a positive feedback loop of improving my English which is at a current state of roughly an IELTS band 7 score or a low C1 (CEFR). I was really bad at English during school by the way. I almost did not pass a grade once due to my terrible English.

4. Communication

Mindfully practice clear communication. Which I just did. #learninginpublic

phantombit profile image
Radomir Wojtera

A little late to the party but my fav one, I learned recently

"First 90% of the project is much easier than the other 90%"

jlrxt profile image
Jose Luis Ramos T.

Leer, entender,practicar y hacer proyectos.

koabrook profile image

Read code backwards line-by-line to understand your code better and identify obvious errors 👍

stephenmirving profile image
Comment marked as low quality/non-constructive by the community. View Code of Conduct
Stephen Irving • Edited on

Am I missing something on this one? It seems so meaningless and up its own ass.

"Software is not the goal, it is the by-product. This is not about writing software, this is about providing value."

Literally every job in the world is about providing value. That is like a furniture builder saying, "Pffft! My job is not about building chairs and tables. No no, the chairs are merely the by-product. My job is actually about providing value to people who want to sit."
**Sniffs own farts vigorously**

It is not a lesson or actionable advice for a career (or anything else), it is just incredibly pretentious and trite. I hate to think about what those in blue-collar professions would think if they heard a programmer say that. As a former blue-collar worker myself, I believe I can wager a pretty close guess...

And regarding the last one, what kind of advice is it to tell people not to care about best practices? That is awful advice. That is no different than saying, "Stop learning how to do things correctly".

maxart2501 profile image
Massimo Artizzu

Am I missing something on this one?

Yes, I think you are.

Mind you, it's not like they're saying that "by-products" are a bad thing in any way. Or that the effort to make them is any less appreciable. It's about reaching a goal rather than making an exercise of style.
If, at the end of everything, you end up saying: "This codebase is majestic, but... what does the app actually do?" You know you've failed to provide value.

Blue collars hardly have any decision making chances, but there are also developers that just have to do what they're told. They don't get to see the overall picture, and won't see the value they're providing. Like bricklayers.

But fortunately not everything is black or white. The boundaries are blurred, especially for us developers, so we can at least question what we're doing. In fact, it's actually a valuable step for personal and professional growth.

So, strive to reach for the value, even if you don't take the final decisions.

For the last one, it's more or less the same thing. It's a tweet, so the context is a bit lacking, but I think the author meant that applying best practices just for the sake of it is meaningless.

Or maybe just ask him: it's a public tweet after all.

All in all, I think your post is a missed chance to ask for clarifications. You jumped to a lot of conclusions. If you deem those folks a little professional, you can ask them what made them think what they wrote, and spark a healthy debate. 👍