The common mindset that I see fast-growing developers have

They are slow

Often I see many developers focus on speed. during some decision-making discussions he already thinking about implementation at the code level, after the meeting, immediately opened VScode and code, the test was only a “refresh page”, and no bugs came out, He fixed it fast, and new bugs came again, and fixed again, fast.

Does it sound good? no. looks bad? yes.

Only a few developers, during the design phase, think through the flow and use cases and start asking questions. design test cases, and write test cases. interfaces, implementation, inject concert class into abstraction, run.

I won’t say 0 bugs, but much less.

Often I see some devs reply to the message very fast.

“Can you get this done within today?”, “Of course. pushing a fix now”, and “Try again now”.

“Is this easy to fix?”, “Yes, give me 10 mins”.

“What is the reason for this issue?”, “I think it should be a data issue, not a bug”.

Responsive to simple questions is good. however, not all the questions are so simple to answer immediately, spend your time to find out, no one will blame you for slowness.

For other developers, I see they work a “smarter way”.

“Let me discuss it with my team and get back.”

“Based on the provided information is still hard to tell what is the root cause. Could you please also get logs under X folder? Thanks”.

Mentor

“Look at X. He joined as a fresh graduate, but I feel he has 3yrs+ exp”.

I saw this happen 2 times. different companies.

One thing these 2 guys have in common — a mentor.

Most of the junior devs are waiting for some nice “mentor” to come into their life help them to grow. however, most of the time, this won’t happen.

Even if It happened. You or your mentor may change companies. and you need to wait again.

The only thing you can carry is the “be a mentor” mindset.

Mentoring and asking for help is a completely different mindset. writing and reading are different. or like when you look at I/O, output and input are different. helping and waiting to be helped is different, assigning tasks and waiting to be assigned is different.

Proactive and passive are 2 different modes.

And yes, being a mentor is the first basic step to being a senior or team lead.

Even if you only joined a company for 3 months, and if someone else joined for 1 month, there must be knowledge or pains you have been through that can be shared with.

To help someone resolve issues or remove roadblocks is a completely different feeling than solving your own problems.

Be a mentor instead of finding a mentor. switch mindset, today.

A secure mind

I see many devs missed this. when writing functions, there is no basic type checking or validation. or using some library with session fixation. this is just bad.

Missing a small validation could result in big issues, like remote code execution, XSS, or SQLI, loopholes.

When you worked enough years, and when one security breach happens. company collapse could be the worst case. lawyers after lawyers.

Such cost is not something a startup or middle-sized company can take.

There should be a place holding for security to trade off some performance for security. security should always be prioritized.

Those who keep security in mind, and voice out the trade-off in VP and O-level meetings. they stand out, easily.

In Detail

During interview. I often see CVs mentioning “Supporting a large number of user sessions online”, or “Archived big performance boost for X module”.

When I asked “How large is large? and how you measured it. could you elaborate more on the testing process, what is the spec of the testing machine, test data, how to data is ingested into the system, and how it is being processed? and, which tool do you use to monitor the resource utilization measure the performance?”

Very few people remember all the details. most of them justify the results by ‘the issue is gone’ or ‘based on user experience, the login time is much faster’.

Nothing wrong with that. the difference is still the mindset.

End-users measure the result by trying out the feature, clicking a button, or refreshing a page;

When some scientists verify some results, they go to labs, set up a repeatable test, execute the steps, and get the results.

Engineer measurement is kind of between scientist and end user, set labs, generate and load in test data, record the “before” and “after” logs, process logs, and get the comparison results.

And sometimes I have seen the whole approach stretched off. because we didn’t consider the “storage limitation details”.

Devs solve problem after problem. because we like it.

Most of us stop at “It just worked” “Concurrency issue”, or “not enough memory”.

Very few devs ran into the rabbit hole and found out what was going on. yes, many times they didn’t find the root cause after spending hours. however, they always can find some other problems on the go, most of the time. time is not wasted.

They revealed the issue earlier and fixed it earlier. agile works this way.

Detail is a key differentiator of fast-growing developers.

but why

Many 1:1 meetings. I always encourage my team to think about the “why”. not only when coding, but also in life decisions. like this one.

“What do you do in your spare time?” I asked. “Well, I study some AI stuff. and also the new X framework”

“Good. why do you learn AI stuff, Do you like it?”

“Just keep up with the trend. Keep my hands ready for the future.”.

“Are you stressed?”I asked.

“Hmm maybe, I don’t know. I see many of my friends switch to AI programming and get much higher pay”.

“I see, you want a raise. I can help to talk”.

“No, I am good with my salary. just I see many people hopping jobs and got a good increase”.

“That’s true. and I do think most of the company salary raise policy sucks. They never raise until promotion, and most of the employees only got <5% a year. which is like almost nothing If we take inflation into account”. I said.

“You mentioned you study every day, and It seems you are worrying about falling behind in the industry; for this point, I want to share with you, ask yourself, what do you like, is it LLM? or vector database? or some mathematical theory behind it? find out what you like, and learn it. never put yourself under pressure to do something.”

“For the job hopping. yes, I know there are many stories like that, and I did it myself in my early years. If you do need more money and somewhere can offer you much more, go for it, and after years if you want to come back, join back again to earn more money (hop back again)”.

He looked at me very surprised. “Is this possible? are you kidding me?” He asked. Of course.

“If you found a better place, why I should stop you; If you left and came back for some other reasons(met a**holes politics), bring more experience and earn more money. I am happy for you.”.

One guy in my team did that: quite joined back. we worked together for 8 years now.

Be clear in mind about what you exactly want, go for it; spend your time wisely, why are you doing that, only do something that you like.

Relax.

Conclusion

• Similar to less is more, Slow is fast. spend time in design, coding, tests, and answering a message.
• You will never be a mentor when you always waiting to be mentored.
• Pay attention to details. get into the rabbit hole, do the measurement, bring out numbers, and find the root cause.
• Before you joined a company, why? Wake up every day, why do you work? pay the billing? waiting for promotion? or simply like what you are doing?

That’s all. thanks for reading! see you in next post.