DEV Community: Pierre Olivier TRAN

4 key skills to step up to Senior

Pierre Olivier TRAN — Tue, 05 Nov 2024 15:20:04 +0000

I've been coding for 11 years now, and went from shitty CTO, to junior dev, to junior dev, to glorified junior dev, to senior dev, to lead dev, and then finally, to dev.

As I learned more and more, I took a step back to ask myself if I'd hire the dev I was 5 years ago. And truth be told, I would not. Because as I gained some experience through the year I also changed my standards when it comes to code quality, and to what I consider to be a senior dev. So, without further adieu, here are the 4 things I consider when hiring a new dev.

Product

This is, by far, the most important thing I look for when hiring a new developer. I'd rather have a dev that is a bit less experienced, but ask questions about the product, then a killer dev that has no interest whatsoever in what he's building. It's not about the idea of discovering the product, it's about your ability to question why the product was built this way.

Patterns

A junior dev will struggle, because he's still learning. A senior dev will also struggle, but he knows some patterns that will save him some time. With the rise of AI coding assistant, we also noticed an increase in "lazy" devs.

Don't get me wrong, if your AI assistant saves you 30 seconds by completing some basic stuff, that's great. But if you rely on your assistant to deliver a piece of code you don't understand, it's a lose-lose situation.

When I'm facing a new feature, or a new pattern, or any problem that requires learning something now, I know I'm going to struggle for a bit, and that's the beauty of our job: we fight, fall, but overcome. Now, your responsibility, once you find a solution and the solution has been validated by your team through a thoughtful review, is to write down your piece of code. I'm using obsidian as my note taking app, and it saved my a HUGE amount of time. From well-documented pieces of code to custom CSS styling, I got it all.

And the best way to discover said patterns is to work on side projects. If we're considering web development, I expect you to be able to handle a few basic patterns: authentication (and maybe authorisations), web sockets, database operations, routing...

Communication

I'm not talking about your ability to talk on a daily basis with every single member of the team, I'm talking about your ability to raise your hand when you're facing an issue. I have never ever blamed a dev that came up to me and said he was stuck. Any complication you face is an opportunity for the team to discuss, bring up new perspectives, and improve. But communication goes beyond this: when coding, your ability to communicate is defined by how clear your code is. In my current company, our only meeting is a 5 minute daily meetup that goes like this:

Yesterday I worked on X, it went well, I'll keep on working on it today
Ok, yesterday I worked on Y, I'm a bit stuck on [some topic], I'd appreciate it if someone could take a look.
Sure, let's talk about it.

This is how you build trust, reliable code, and meaningful interactions.

Now, the rules of written communication.

I've worked in companies that required a lot of comments, and I've worked in companies that said that comments are only necessary when explaining a complex piece of code: in the end, if it's not a written rule, the decision is yours to make; but remember: this code is your responsibility, and if a new dev discover your code, 6 months from now, and starts crying in despair because you named your most important variable "foo", you lack the communication skill I'm talking about.

Team player

I took English classes at school. Yet, 99% of my vocabulary comes from music (all hail Aesop Rock), video games and movies.

Same thing goes for coding: I learned a LOT of stuff from coding school and from my previous jobs, but most of my coding experience comes from side projects. Which is a bit of a bummer: sure, you move faster when working alone, but you go FURTHER when working as a team.

Which means, you have to learn how to be a team player. And for this, I have only one rule: be good. Ask yourself when you hate the most when working as a developer. Here are a few of the things I despise, even though I love my job:

54 files, 3k lines of code changes in a single merge request. Just like Andy's old toys in Toy Story 2, this will either end up collecting dust in our list of MRs, or go straight to the trash.
Squinting my eyes when reading a piece of code. Good code is like a good book: it tells a story. I don't. Want. To re. ad. a piece of co. de that looks As if you were having a stroke while writing it. See, that's hard to read, huh ?
Linter and CI are your friends. Which means, if you write a critical piece of code, please test it. And if for some reasons your company does not include automated CI/lint check in your git flow, please make sure that your code does not break anything before asking for a review.
When asked for a review, do not wait. In a perfect world, a MR should not live for more than 4 hours.

Now, obviously, on my end, I'll make sure to provide the best developer experience during our interviews. Which means, I will never ask you to send me a technical test that took you half a day to complete. I don't believe in 7-steps process, nor in online coding tests. Show me a project you're proud of, let's discuss it for a few hours, and I'll probably be able to assess your expertise.

This is the level of skill that I expect from a senior engineer. And this is the level of respect that any interviewer should give to someone applying to that position. Because in the end, a good senior engineer is a cornerstone.

Hone Your Craft

Pierre Olivier TRAN — Tue, 09 Jul 2024 09:46:52 +0000

I've been a dev for 10 years, and it's been a bumpy road, full of bad choices, a few good ones, and a lot of interesting lessons.

Let's get to it.

the climb.

I started in the worst possible position as a web developer: CTO. I started my own company, had no professional experience whatsoever, just a box of tools that I barely knew how to use, and the confidence that goes with any idiot that just came out of a double degree in entrepreneurship and software engineering. In other words, I was a ticking time bomb, the most fertile ground you could think of for a proper burnout. And Burn out I did.

I didn't know how to code properly, yet I was coding. I never stopped to think and reflect on my life, mostly because I had no life. I had customers, and I was a slave to my "product". And my product was shite.

But we had customers. So I pushed on. And when we finally crashed, what did I learn ? Did I find a job as a junior developer in a nice company that could help me get better through the help of a wise, caring mentor ?

No sir. I made the complete opposite. I started another company. And guess what. Second burnout in a row. Long story short, it took a miracle to get me out of here: I won a hackaton, that earned me a trip around the globe. Finally, I had time to breathe. And I learned the first importants lessons:

In between jobs, take some time off. Relaxation is not a reward, it's a requirement toward any meaningful achievement.
Start small. Be Humble. Sites like roadmap can help you tremendously. Because in life, everything valuable takes time.
It's OK to ask for help, both for your job and in your life.

the peak

after 3 years of building abominations through carefully sabotaged codebases, I decided it was time to move on. And so, I joined the worst best company of my career.

This company had everything a 27yo could ask for: early stage, young team, only rowdy guys (our slack history would send us all to jail), afterwork twice a week, and a codebase that was so toxic it's a miracle it didn't spontaneously exploded. but boy did we have fun adding GIFs and sparkles and hover effects.

And guess what ? Another terrible thing happened. We raised funds. Like, a lot.

Raising funds when your product is unstable is not unlike throwing water at a raging kitchen oil fire. You're in for a nasty surprise. And when your customers start asking for simple features, but your codebase is but a glorified diarrhea, you start to think "hmm, maybe we should have used Typescript".

Because asking the following questions really hurts:

Why does our landing page take 8 seconds to load ?
Was it such a good idea naming that variable "x" ?
How did we manage to turn our most important user story into a 1800 lines function that is, obviously, not tested ?

So, we did what we had to do. And it felt soooo good.

rm -rf client
rm -rf api

Yup. We started new. And let me be clear: the only reason we could do so was because we raised funds. We were overpaid kids playing around with bits of code that had nothing to do with our core product.

it took us 2 months to rebuild the app, with the help of a great freelancer that helped us design, build and test the app.

For the first time in my career, I understood what it meant to believe in a product, to fight for it, and to nurture it. Our backlog slowly started to pile down, our customers were happier than ever. But karma is a bitch, the pandemic came, we "crashed" (AKA, the company didn't have any money to pay the tech team), so we all left, hoping that things would get better, but just like pauses don't work in relationships, they don't work in jobs either. I moved on, and evolved into a brand new kind of idiot. But in the mean time, I learned some new lessons:

Building a great product takes time and conviction
Its a good thing to have a nice team. It's better to have a good team. It's a miracle to have a team that is both benevolent and efficient.

the fall

From 2020 to early 2023, I never managed to keep a job for more than a few months. Why ?

Because I was stupid. That's why. Here's a program to completely fuck up your life:

Be nice and charming
A company reaches out to you
Interviews go well, because you are self-confident
Your get hired.
You're good at talking, but not good at coding
Because you have 6/7/8 years of experience, your salary is HUGE.
Company slowly realises that you are not qualified for the job.
Everyone loves you, except the people that work with you on a daily basis. Think "Oh, we just hired a golden retriever to code our most anticipated feature. He can't code whatsoever, but he's a GOOD BOI"
HR thanks you and ends up your introductory period.
back to step one.

I did this not one, not twice, but 5 times in a row, blissfully happy, not realising that the only reason I was getting hired was because I'm good at selling myself. After the 5th failure in a row, karma struck me. And almost killed me. Literally. But more on that later: the main issue with this endless cycle was that staying in a company for such a short amount of time is not enough to make you better: you cannot get a grasp on the product, you do not have enough time to start building something meaningful, and because I was not good at coding, I couldn't even help the junior devs (who were sometimes better than I was).

So I learned the most important lesson of them all:

I suck, and that's alright, as long as I'm able to acknowledge it and decide to get better.

Which leads us to the main part of this story

the forge

Early 2023, I started reading. A lot. About coding, about health, about habits. And I completely reshaped my life.

Here is the complete path I took:

Acknowledge

You have to understand that the quality of your work is merely a reflection of your life, and therefore, of your habits. And my habits were a mess. From video games to sleepless nights, from alcohol to sedentary lifestyle, I had it all wrong.

I used Google calendar to write down what my weeks look like. Every single thing, from sleep to work to fun. And I picked 3 things I wanted to change.

Take care of my health
Stop playing video games
get better at coding

Act

So, that's all I did. I removed everything that was not aimed toward that goal. Sold my gaming computer, subscribed to a weekly delivery of healthy food, set my alarm clock to 6 in the morning, hit the gym. It took me 3 months to turn this into a routine.

Here's how the day unfolds now:

wake up at 6AM
Drink water
hit the gym for 60 minutes
cold shower
Get to work
set my to-do list using calendar
Get back home
read/practice guitar
No more screen time after 9PM
Sleep at 10PM

My instagram feed went from cat videos and sexy girls to self-help and music. My youtube feed went from video games to coding tutorials and self-development. My salary more than doubled over 18 months.

but here are the key insights:

Went from 4/5 MR a week to 3/4 a day
Went from 20+ comments per MR to 1/2
Went from "senior" to lead developer
Went from 68kg skinny fat to 84kg bulky (I'm 1.84m tall)
went from bragging self-confident to silent self-confident.

Track

Here is the single most important change that I made: I started taking notes. Meaningful notes. I use Obsidian as my note app.

After a workout, I write down my weight, and how much I lifted. Reps, weight, everything.
When learning a new skill/library, I write down valuable bits of code
Every morning, I write down about the previous day. What did I do ? How did I feel ?
Every valuable tutorial/post/video is turned into a new page.
Tags and Links are your best friends.
I organise my notes using this method and this method

Taking notes is not only a great way to keep track of your progress, it also tremendously helps your memory. Reading documentation is not enough, you have to write down what you understood, challenge it, and then use it.

Here are the tools I use on a daily basis:

Obsidian
Google calendar
Minimalist phone. Basically turned my smartphone into a Nokia 3310.
Turned off all notifications
Spotify. Hans Zimmer is the GOAT to get into a state of Flow. As a matter of fact, I'm listening to the interstellar OST while writing these lines.
ChatGPT. It's only getting better and better.
VSCode, zen mode.

And here are the last lessons that managed to reshape me.

Your job is an extension of your day. Not the other way around.
Do the things that matter first thing in the morning. There's nothing more frustrating that coming home after a long day of work and realise that you didn't do anything except work.
understand that everything that is not an investment is a liability.
Keep track of your progress. I use obsidian tracker to keep track of my habits, workouts and so on
Be benevolent. Your goal should always be to either get better, or help people get better. Which is basically the same.

I hope this post will help you get better at whatever you consider to be important.

5 steps to grow from junior dev to senior

Pierre Olivier TRAN — Thu, 23 May 2024 13:01:16 +0000

I've been writing code for eleven years now, and slowly moved from intern, to junior, to senior, to lead developer, with the occasional job as a CTO.

Over the past two years, I've spent roughly 250 hours reviewing applications and technical tests, both on site and online, and helped wonderful teams build great products.

Here are the 5 key differences between a junior and a senior developer. And to illustrate each concept, I'll give examples based on real-life events, that lead either to great success, or tremendous failures.

1 - Ask, Challenge, Believe

Whatever you're working on, it is way easier to build a great product if you actually believe in it. And the only way to build conviction is to ask around. Why am I adding this feature ? Why are we making these changes ? Does my team know about this pattern ?

The key idea here is, you have to believe in the product you are building. You have to build conviction before laying down your first line of code. You cannot nurture any doubt as of why you are shipping this feature, who's going to use it, or how.

In 2020, I was working at a major company in video games. We were hosting an e-sport tournament, and our marketing team thought about developing a scoreboards client app, and plugging it into an eternal API to fetch scores in real time. I was in charge of the technical part, managing a team of 5 developers.

Unfortunately, the same marketing team did its own research for available APIs, and decided to sign a contract with a company before including any tech member in the process.

Which lead to a very goofy meeting, when I finally met my tech counterpart in said company. For 90 minutes, we listened to my manager, knowing that their API was not the one we needed. In fact, I knew half a dozen of APIs that could have done the job, for a fraction of the price.

I went back to my team, and we took a moment to decide how to tackle this issue. To which they answered the ONE question you have to fear when working on any product: "Why do we need this ?". They did not believe in this new scoreboard app. Neither did I: there was no conviction whatsoever.

So, I calmly asked for a quick talk with my manager, and asked him what we needed exactly. He gave my a short list of features, and I told him that it would take roughly 3 weeks to ship them all, and that I knew of an API that could get the job done for 12.99 a month. To which he responded that he already paid the API company in full, for the use of their API and the services of a consultant, for the next 4 months. We're talking 115k euros.

So, I did the only sensible thing to do. I went to my manager's manager, took the blame for the miscommunication, and asked him what to do next. We thanked the API company, we thanked the consultant, and based simply on the small list of feature my manager had given me, we managed to ship the whole project in three weeks. Suddenly, our tech team believed in the project, because we know WHY we were doing it, and HOW we could do it properly.

The key idea here is: a senior developer spends a lot of time building conviction, questioning patterns, and proactively bringing solutions through his knowledge and past experiences. Once your whole team believes in an app, or a feature, you'll know exactly how to code it.

2 - Know your tools

There are thousands of way to add authentication to your app. Or real-time. Or to build an endpoint that fetches data. Which means that there are thousands of way to do it poorly.

A senior dev knows the main patterns to add a feature, and therefore, he can code it quickly, shipping a code that is both clean, reliable, and well documented.

A great way to assess your "seniority" is to take a look at a few numbers:

How many threads do I have on my merge requests ?
How long does it take for my MR to be merged ?
How often am I asked for advices/review ?

No matter how complex your app might be, there are not that many tools that we use on a daily basis. My current stack includes Nest.js, Next.js, tailwind and GraphQL, which can be overwhelming for a junior dev.

So, instead of simply reading the documentation, every time I start working on a new topic, or using a new tool, I document it for myself, using the micro-thesis system. I'm using Obsidian as my Documentation system, but there are a lot of viable tools out there.

Here is my process:

I use my daily note to list my tasks for the day.
If this task requires learning a new skill, I turn it into a link using the [[]] syntax.
As I learn how to use this new tool, I write the best documentation I can. It has to be simple, include pieces of code, be reusable, and include links toward useful documentations.

This way, the next time I'll have to use said tool, and I have to do is search for this page in my Obsidian vault. not only will I have a head start on how to use it, it will also include links toward all of my notes that mention this page, making it easier to decide whether or not this is the right tool for the task at hand.

This also means that, whenever a tool is updated, I must update my documentation accordingly. This is pretty much how I keep myself updated on the latest versions of my stack.

Another important thing to keep in mind is the ratio between the time needed to ship a feature, and the price invested in using a third part application.

Let's say you are building an app that required both authentication and authorization. Maybe you have an repository you can fork, maybe you don't. If you don't, it will take you some time to add these features. In the mean time, libraries and freemium SAAS might help you setup your authentication in no time.

If I'm building a small app, I'll always go for free solutions for everything I don't feel like coding myself. Let's keep it simple: a freelance software engineer charges 1000 dollars a day. Adding a proper authentication might take 2/3 working days. in the mean time, adding and configuring Clerk/Kinde/Lucia takes roughly an hour, and these solutions are free.

The key idea here is: your tools are not limited to your coding skills. Just like in the old RTS games I used to play, consider both your time, money and skills as resources, and pick wisely which one to use, and how much you want to spend.

3 - Code Small.

Being a software engineer is awesome. It feels like having a bottomless box of Lego bricks at your disposal. You can use them to build whatever you want, from the smallest car to the biggest city.

But when it comes to professional projects, you have to understand that every line of code is a liability. Which means, the less you code, the more reliable your codebase is.

So, here are the 3 golden rules I try to live by:

A merge request solves ONE issue.
If I need to use a bullet list to explain the changes I made, and said bullet list includes more than 3 or 4 elements, I probably messed up.
The ability to properly split up your code requires experience, and is as important as the actual performance of your code. Both on front end (think composition in React) and back-end (think modules/services/whatever architecture you are using to split your code into small manageable chinks)

if you do so, you'll manage to ship faster, build confidence within your team, and quickly setup a flow that'll allow you to deliver value on a daily basis.

On the other hand, you know that a pull request that affects countless files, is not properly documented, and includes loads of code smells will either be a nightmare to review, and will either stay open for a very long time, or will simply be closed. I usually go for the second option, by asking to split its content into smaller parts.

4 - Reviews are gold

Consider this: as a software engineer, 90% of your knowledge comes from experience. Actual work experience. And said experience comes from mistakes and failures, both yours and your teammates'

The lesson here is, your main goal as a senior developer is to provide and receive feedback. As we said, there are thousands of ways to add a feature, some are better than others, and you don't have enough of a lifetime to try them all. So, ask around and collaborate.

Here is the usual process I follow when reviewing a MR:

Understand the underlying goal. "What are we trying to achieve here ?"
"How would I code it ?"

From there, I'm more of a multi-commits kind of guy, so I simply review one commit at a time. If, at any point, I don't understand something (why do you use this lib ? Why did you name it that way ?), I add a comment.

Nowadays, I'm working as a lead developer, and my team has a wide range of seniority. Which means some MRs will receive a couple of comments (usually questions or interesting debates), and some others will receive 54 comments, from naming to logic to performances. In which case, I switch from review to peer programming.

If you are managing a team, note that the amount of comments on any given review is an actual metric for the quality of code.

5 - Own it

It usually takes me about two months to decide whether or not I'm confident on the level of expertise of a coworker. If my standards are met, I don't have a problem with telling them that they are responsible for 99% of the development process, from the tools they use to the patterns they pick. The last percent is the review, and the consequences. I want them to be owners of the code, but I'll be the custodian of their wellbeing.

At the end of they day, you have to embrace ownership on your decisions, both personal and professionals, which brings me to the following personal statements:

I'm way more efficient at work when I do the things that matter to me first thing in the morning. And not a single one of them is work-related
This includes drinking water, moisturising, flossing, workout, meditate.
Keep track of everything that matters. The good thing is, there are not a lot of things that matter.
Communicate to find your love/delegate balance, using the following chart:

As a senior developer, you are responsible of both the quality of the code you ship, AND the quality of the code you review. As a manager, you are responsible of any given failure that comes from either your code, or the code your team ships. Which means that the BEST way to ensure code quality is not only to make thoughtful review, but to create the best possible environnement so that everyone can perform well

TL;DR

A senior dev would read the article.

Flowing Code

Pierre Olivier TRAN — Wed, 13 Mar 2024 12:54:30 +0000

In 1970, psychologist Mihaly Csikszentmihalyi named the state of mind known as flow. Sharing many similarities with hyperfocus, it is best described as a moment of clarity in which one is fully immersed in a state of intense focus.

If you've been coding for a while, you've probably experienced this. It requires a specific setup, but it always ends up in a tremendous amount of work being accomplished in little time.

I like cooking, so I though about introducing this topic as a recipe.

To cook a full batch of Flow, you'll need to following ingredients:

A full night of sleep. Let the dev rest long enough to feel energized.
Water. Truth be told, I'm not sure this one is absolutely necessary, but I like to start off the day with a large glass of water with a pinch of salt and a few drops of lemon juice. Mostly because tap water tastes like granite around here.
A challenging task. It is nearly impossible to reach a state of flow when working on something easy/repetitive. If the task at hand requires you to replace a bunch of icons throughout a large scale web application, you don't need a state of flow you need ~~an intern~~ a large amount of coffee.
A clear goal. I like to work with user stories, to know exactly what's expected. Pen and paper are enough, just write down what you need to accomplish, and cross it off as you progress.
The knowledge. Ideally, you should already be experienced enough to know how to build whatever you're working on. That means no chatGPT, no stackOverflow, just pure coding.
Needless to say, ditch all external distractions. Phone must be in airplane mode, notifications are turned off, VSCode is in zen mode.

The goal is to setup an environment that'll naturally bring you into this state of flow. You cannot force it, you need to let it slip in.

The React Way - 1

Pierre Olivier TRAN — Tue, 12 Dec 2023 14:36:56 +0000

Just as a well-organized codebase is key to the maintainability of a software project, understanding and implementing Composition in React is crucial for creating efficient and manageable user interfaces. Drawing inspiration from the principles of "Clean Code," let's explore how Composition in React can be akin to the art of code splitting and maintaining a clean, orderly codebase.

What is Composition in React?

Think of your React application as a large codebase. In "Clean Code," one principle is to keep things modular - small, focused modules are easier to maintain than large, monolithic ones. Composition in React works similarly. It allows you to create a complex UI by combining smaller, reusable components, much like breaking a large codebase into manageable modules.

BUT WHY ?

Coding is good
Coding small is better
Coding small and clean is best

And just as any feature can be split into smaller, more manageable features, so does your React codebase.

Example of Basic Composition

Consider a scenario where you're building a user interface with a Header, Footer, and Content. Each part of the interface is like a module in a well-organized codebase:

function Page() {
  return (
    <div>
      <Header />
      <Content />
      <Footer />
    </div>
  );
}

function Header() {/* ... */}
function Content() {/* ... */}
function Footer() {/* ... */}

Each component (Header, Content, Footer) is self-contained, similar to how each module in a codebase should have a single responsibility.

Props and Composition

In "Clean Code," clear and concise function signatures are vital. Similarly, in React, props should be used to make components flexible yet straightforward. Props are like function parameters, allowing you to pass data and behavior down to child components, ensuring that each component remains modular and single-purpose.

function Content({ articles }) {
  return (
    <div>
      {articles.map(article => <Article key={article.id} {...article} />)}
    </div>
  );
}

function Article({ title, content }) {
  return (
    <div>
      <h2>{title}</h2>
      <p>{content}</p>
    </div>
  );
}

Higher Order Components and Composition

Higher Order Components (HOCs) in React are analogous to decorators in software design, as described in "Clean Code." They add additional functionalities to components without modifying their core responsibilities.

function withLogging(WrappedComponent) {
  return function LoggingComponent(props) {
    console.log('Component rendered with props:', props);
    return <WrappedComponent {...props} />;
  };
}

const LoggedContent = withLogging(Content);

This HOC adds logging functionality to any component, enhancing its capabilities while keeping the original component's purpose intact.

TL;DR

Composition in React allows for building complex UIs with a similar mindset. By breaking down UIs into smaller, reusable components, managing props effectively, and using patterns like HOCs, you can create clean, efficient, and maintainable React applications. Embracing these practices will not only make your code more understandable but also enhance its overall scalability and robustness.

Investment as a software engineer

Pierre Olivier TRAN — Wed, 22 Mar 2023 17:00:59 +0000

Introduction

The book "Rich Dad, Poor Dad" by Robert Kiyosaki has inspired countless individuals to take control of their financial lives and break free from the constraints of traditional employment. The lessons in this book can be applied to various professions, including software development. In this article, we'll explore how senior software developers can use the principles found in "Rich Dad, Poor Dad" to enhance their careers and personal growth.

Financial Education

The book emphasizes the importance of financial education, encouraging readers to learn about money management, investing, and wealth-building strategies. As a senior software developer, you can apply this principle by:

Continuously learning about new technologies and programming languages, increasing your market value. Stay up-to-date with the latest advancements in your field by subscribing to newsletters, blogs, and podcasts. Allocate time for regular self-study or enroll in courses to keep your skills sharp and stay ahead of the curve.

Acquiring knowledge about personal finance, including budgeting, investing, and saving for retirement. Seek out resources such as books, articles, and online courses that teach you about financial planning and investment strategies. Consider working with a financial advisor to create a personalized plan that aligns with your long-term goals and risk tolerance.

Understanding the business side of software development, such as project management, sales, and marketing. Familiarize yourself with the process of software development from idea to market, and gain insights into the sales and marketing strategies that help companies succeed. Attend workshops or webinars that focus on these areas, and consider earning certifications to demonstrate your understanding of these aspects.

Diversifying Income Streams

Robert Kiyosaki advocates for creating multiple income streams to secure financial freedom. As a senior software developer, you can diversify your income by:

Freelancing or consulting outside your primary job, which can provide additional income and the opportunity to work on diverse projects. Build a professional portfolio showcasing your skills and past work, and use platforms like Upwork, Freelancer, or Toptal to find clients. Establish a clear contract with your clients, outlining the scope, timeline, and payment terms of the project.

Creating and selling software products or apps, generating passive income through sales or subscriptions. Identify market needs and develop solutions that cater to those needs. Consider partnering with other professionals, such as designers and marketers, to create a well-rounded product. Utilize platforms like the App Store, Google Play, or Shopify to sell your software or app, and employ marketing strategies to drive traffic and sales.

Investing in stocks, bonds, real estate, or other income-generating assets. Develop a diversified investment portfolio that aligns with your financial goals and risk tolerance. Explore various investment options, such as index funds, individual stocks, or real estate investment trusts (REITs). Consult with a financial advisor or use robo-advisors to guide your investment decisions.

Building a Strong Network

"Rich Dad, Poor Dad" highlights the significance of networking and building strong relationships with like-minded individuals. To apply this principle, senior software developers can:

Attend conferences, meetups, and workshops to connect with fellow developers, entrepreneurs, and industry leaders. Engage in conversations, exchange ideas, and foster professional relationships that can lead to potential collaborations or job opportunities. Make a lasting impression by being open, approachable, and genuinely interested in others' experiences and perspectives.

Collaborate on open-source projects or contribute to online forums to showcase your skills and knowledge. Open-source contributions not only help you refine your skills but also demonstrate your expertise and commitment to the software development community. Online forums, such as Stack Overflow or GitHub, allow you to provide valuable insights, answer questions, and engage with fellow developers from around the world. By actively participating in these platforms, you can establish a reputation as a knowledgeable and helpful professional.

Establish relationships with mentors and mentees, fostering mutual growth and knowledge exchange. Identify experienced professionals who can provide guidance and support in your career journey, and offer your expertise to less experienced developers. Mentorship relationships can lead to new perspectives, skill development, and opportunities for both mentors and mentees.
Leveraging Assets
Kiyosaki emphasizes the importance of owning assets that generate income, rather than liabilities that drain resources. As a senior software developer, you can apply this principle by:

Investing in continuous professional development to maintain and enhance your skillset, making you a more valuable asset. Allocate time and resources to learn new programming languages, frameworks, or tools that are in high demand. Stay current with industry trends and best practices by participating in webinars, reading industry reports, or joining professional associations.

Acquiring certifications and attending workshops to improve your expertise, increasing your earning potential. Certifications, such as those offered by AWS, Microsoft, or Google, can validate your skills and demonstrate your commitment to professional growth. Workshops and training sessions can help you master specific technologies or methodologies, making you a sought-after expert in your field.

Building a robust online presence through blogs, articles, or podcasts, demonstrating your expertise and attracting potential clients or employers. Share your knowledge and insights by writing articles or creating tutorials about the technologies and practices you're passionate about. Establish yourself as a thought leader in the software development community, which can lead to speaking engagements, freelance opportunities, or job offers.

Developing an Entrepreneurial Mindset

"Rich Dad, Poor Dad" encourages readers to think like entrepreneurs, taking calculated risks and seizing opportunities. To adopt this mindset as a senior software developer, you can:

Develop a growth mindset, embracing challenges and viewing setbacks as opportunities for learning. Cultivate resilience and persistence by actively seeking feedback, experimenting with new ideas, and learning from failures. Embrace change and adaptability, recognizing that the software development industry is constantly evolving.

Be proactive in identifying and solving problems, demonstrating your value as a developer and leader. Instead of waiting for instructions, take the initiative to propose solutions, optimize processes, or introduce new technologies. Show your ability to think strategically and consider the long-term implications of your decisions, positioning yourself as an indispensable member of your team or organization.

Look for opportunities to innovate and create new solutions, both within your organization and in your own projects. Stay curious and open-minded, exploring emerging technologies and identifying potential applications for your projects or clients. Encourage a culture of innovation within your team, fostering an environment where ideas are welcomed, and creativity is celebrated.

Conclusion:

The principles found in "Rich Dad, Poor Dad" offer valuable guidance for senior software developers looking to advance their careers and achieve financial independence. By investing in financial education, diversifying income streams, building a strong network, leveraging assets, and developing an entrepreneurial mindset, senior software developers can enjoy the benefits of a rewarding and fulfilling career. Embrace these lessons, and you'll be well on your way to creating a successful and prosperous future in the software development industry.

The unspoken curve

Pierre Olivier TRAN — Wed, 14 Sep 2022 13:43:36 +0000

It's ok to learn, it's OK to ask for help, and most importantly, it's ok to fail. These things are the foundation of any progress.

Here are the 4 elements that will eventually turn anyone into a great developer.

Research

This is the first step that any developer will have to face. Our job is ever-changing, new frameworks/libraries are released every day, and you have to be able to dig into the documentation/patch notes/whatever just to get a better understanding of what you're doing.

Some common mistakes are to immediately ask for help. Instead, ask yourself these simple questions: "What am I trying to do here? Do I know something that works similarly? What does this term mean?"

Even after a decade of working on web projects, we still stumble upon new concepts, and it always comes down to the very first rule of software development: RTFM.

Tips and tricks

First of all, a lot has changed since I started using daily.dev as my browser default page. Every day, you discover new concepts or updates on great products.

You can also use Github Trending to discover the latest trends.

StackOverflow will be of great help IF YOU KNOW HOW TO USE IT. Let's just say, if you are a beginner/medium-level developer, there's a 99.9% chance someone already asked your question, and someone already answered. In the end, StackOverflow is not about finding answers, it's about finding the question.

Another GREAT way of learning is to find a mentor. It might be a colleague, a friend, a Discord server full of cool developers (you can find a LOT of these, I love to create a private room every now and then to discuss about patterns)

Last but not least, side projects. I started bloks a couple weeks ago, and it helped me tremendously in planning a clean React context, and managing my time.

Question

Another huge chunk of your job is to question everything, including and especially yourself. Here are the top 3 questions to ask before starting anything new:

Do I really need it?
Do I REALLY need it?
Do I have everything to achieve this task? (Including knowledge, tools, a clear state of mind, and enough sleep)

Again, you do not know everything about software development, and that's alright, we are all just a bunch of ever-learning apes.

Again, if you're part of a team, it is your responsibility to question product-led decisions every now and then. If you think that a feature is not really needed, or not a priority at the moment, or way too heavy for ROI, you have to say so.

Once you're sure about your product/feature, you'll see that every now and then, you have to question yourself, your decisions, and your skillset, but more on that later.

Planning

This is my favorite part because the only thing I love more than coding, is nice coding.

But what is nice coding, you may ask? Nice coding is the art of producing code that will be lean, efficient, and can be produced without too many iterations. And it takes a lot of time to be proficient in nice coding.

My workflow

It might sound a bit egotistic, but here's my current workflow, and it works pretty well:

Get enough sleep. I cannot stress that enough. A good night of sleep will be the difference between a couple hours of nice coding, and a ruined day. In fact, sleep is so important to me that my "sleep-budget" exceeds my tech budget 8-to-1. And I run on a full Apple setup.
Read the specs. You have to know exactly what you are trying to build. Doubt is the enemy of nice coding, take all the time you need to have pixel-perfect specs before laying a single line of code.
Paper + Pencil are your best friends, and most of the time, they'll solve your problems/questions. For any given problem, you can create a draft on paper. If you need an external point of view, do not hesitate to share. I use miro to create flowcharts, and it saved me a LOT of time because anyone can comment/discuss your draft.
Testing. If I had to pick ONE key skill for any senior developer, it would be the ability to test your code. Everything can (and should) be tested, and if you feel like testing a new feature is a pain, it probably means that your architecture is suboptimal. You have so many tools today to test your application, from jest to real-time mock generation. Quite frankly, whenever interviewing a candidate, or reviewing a MR, if I don't see a test, I start feeling nervous.
Timebox your work. As a senior dev, you're expected to produce clean code, quickly. As a junior developer, you're expected to produce clean code, slowly. This will simply allow you to learn clean patterns, that you will eventually master, and reuse. And everyone will thank you for that, even if it means taking an extra week to deliver your feature. But, as you progress, you will have to work faster and get out of your comfort zone. Eventually, you'll be able to estimate how long it would take you to deliver any given task.
Create a nice coding environment. I have ADHD, I tend to let my mind roam every 15 minutes or so => I started using Pomodoro timers and relaxing sounds. I usually eat at my desk when I work from home, so every now and then, I have coffee cups/a plate on my desk. Which I obviously not need for work. So make sure that your work environment is as neat as can be. Again, this requires some questioning:
Do I need another coffee at 7PM?
Is this chair right for me?
DID I GET ENOUGH SLEEP?

Overall, I live by a simple rule: wake up, make your bed, brush your teeth, drink water, cold shower, and then consider all chores at hand. If it takes less than 5 minutes, I do it immediately.

Teamwork

This is the pinnacle of abilities. I deeply believe in the notion of team trust..

You want to work with people that you can rely on, to make everyone's life easier. How performant is your code? How smooth is your reviewing process? How clean are your commit messages? How reliable are you when a teammate needs help?

This is the one ability that most companies will look for, and this is the n1 parameter that will help you maintain a great level of trust, respect, and quality in your codebase and in your team.

And the only way to achieve this level of quality is simple:

Do your research
Question yourself and the task at hand
Plan accordingly

There you go, my 2 cents on how to effectively progress as a software developer.

TL;DR

No, for real, read it.