DEV Community: TuWang

$$ Every Wrong I Did As A 'FAANG' Software Engineer Before 30; What About You?

TuWang — Fri, 29 Apr 2022 17:07:15 +0000

Youtube: $$ Every Wrong I Did As A 'FAANG' Software Engineer Before 30

If you listen to Gary Vee, '30 is the new 20', all blood-pumping vibes; look forward, never stop the hustles lol.

However, I wish I could slap my 21-year-old self: calm down, go find the right internship, do leetcode. Nothing else matters!

(slapping myself now ... a lot other stuff do matter: relationship, physical/mental health...)

We are all in this tech bubble, maybe my stories are relatable - guess what, we all mess up. This video is a little retro of my personal failures, studying and working in the states. I wish I could have done better.

I'd love for you to watch the video, but here is the three points discussed:

I. Chasing After Others' Goals
II. Never Landed The Right Tech Internship
III. 'I Will Figure It Out Later'

Through the past 8 years, I've observed so many people's success in the tech industry, which humbled me deeply. I often joke about my mistakes - some were very personal - it makes me appreciate more the uncommon successes.

The internet is now full of breathtaking role models. To they raise my anxieties. I just hope my humbled stories (this video!)can take you for a laugh.

Questions

So here are the topics for discussion!

What did you do well or otherwise in the tech industry?
What would you do differently before your first job? or before college graduation?
Would you trade your time to grind leetcode?
Is there any offer that you regretted (joined or rejected)?
How can you be sure that Software Engineering is the right career path for you? Or is it just sunk cost so we've all been riding alone?

I Miss The Good Old Backend Days - What Do You Prefer?

TuWang — Sun, 03 Apr 2022 23:22:34 +0000

I've transitioned to product-facing engineer for about 2 years now. I wouldn't call myself a 'front-end' engineer or a 'full-stack' engineer - I don't think I'm qualified either. I've departed the pure Backend service engineer role. Now I'm working on product features, where I occasionally tap into different stacks but mostly focusing a smooth product experience.

What do you prefer? Backend or frontend? Web or Mobile? Infra or Product?

The Backend Role

I'm aware of many public definitions of engineers (frontend, backend, software vs hardware, web vs mobile, or the glorious full-stack...etc). To me, I've only had 1 role previously at Amazon for 4 years - a backend engineer working on services. That means my role is primarily about designing and building backend APIs.

This has changed since I joined a new company. It has been 2 years since I look at API designs - I certainly miss it.

What I Missed the Most

The decision making processing was 'simpler'.

The whole theme was about the API contract and use cases. You keep on finding corner cases and solving them, where the 'end user' is usually another team's engineers. You can disagree on many things, but all conflicts come down to certain set of mandatory use cases and another set of non-MVP use cases.

The decision making is simple in a way that, backend system do not often have to worry about the human factor - it's not user-facing. Engineers have a lot more control of the end to end system design.

What I Don't Miss

I didn't enjoy the fact that my backend work was not usable by human beings.

At dinner table, I'm sure we all get these questions: what do you work on? My answer is often vague because - when I say 'I work on backend system', it's really difficult for people to visualize or weigh the value of my work.

Working on pure backend team, far from user-facing product, I was lack of many aspects of modern software development. I found out much later that there are engineers who wear many hats: user experience, end to end project timeline, collaborations with other systems. These are critical skill sets to train if I were to lead a team to build something.

Reality

Now when I occasionally bump into people working on backend design - it just reminds me of the goold old conversations I used to have with teammates :)

Once in a while, I wish I can dial back and just work with system that talks to systems.

What do you prefer to work on? Has anything changed in the past years? Backend or frontend? Web or Mobile? Infra or Product?

Making Peanuts in Tech

TuWang — Thu, 31 Mar 2022 20:15:50 +0000

In 2014, I started my first job, which made me $58K in Boston. Even back then, this was a below-average income in the tech industry. Oh wait, I stumbled into the non-tech industry, sad.

It took me nearly 1 year to realize the income gap, and about 8 months to finish the career switch - being an entry-level software engineer at Amazon.

Since then, I made a few more mistakes. Now, compared with my college friends, they are now making half a million each year. Not too long ago, I was just making peanuts.

Check out this video to see why I was making peanuts even with a Computer Science degree.

YouTube Video: They Made Half Million($500k+), I Made Peanuts

Nervously, I Started A Tech Youtube Channel

TuWang — Fri, 11 Mar 2022 08:22:44 +0000

That's the plan.

The marketing expert says to highlight my newborn Youtube Channel: I Failed To Quit FAANG Jobs (Facebook/Meta | Amazon | Apple | Netflix | Google)

I feel like an imposter, as if I'm joining a new company. Others doing so well. Me? huh.

This time, it's about making Youtube videos. About this first upload, I expected 0 organic impression, so no release pressure.

One click - Done.

Now, when it comes to sharing the content to broader audience, I'm nervous. The worries are cliche:

what if people don't like how I present?
what if my point of view is way too narrow?
what if - my accent is horrible?

[EMOTIONAL DAMAGE]

I doubt this video will gain up to 100 views before I upload the next one. But hey, I'd like to take 1 step outside of the comfort zone - now I have your attention.

Thank you for reading. Please consider checking out that video, and if you enjoy it, I'd love to know how you think!

Here is the link again: I Failed To Quit FAANG Jobs (Facebook/Meta | Amazon | Apple | Netflix | Google)

After COVID-19

TuWang — Tue, 31 Mar 2020 20:51:33 +0000

Software Engineers are perhaps used to working from home (or working from anywhere), so that wan't a challenge at all. Silly as it may sound, despite all the horror brought by COVID-19, it has forced me, or perhaps my generation, to reconsider how we live our life.

Human beings are often obsessed with second chances, or should I say, we often abuse second chances: the mindset of, oh okay, I can make it right next time, makes it extremely hard to make any progress today.

Through 2020 we have heard enough of harsh stories about COVID-19, so that's not what I plan to write. My retrospective of life is rather simple and silly.

breakfast: orange juice, avocado bagel with salmon, onion and eggs:

It hits me hard that for 30 years I haven't built any daily routine; until now, forced by the virus, of course, I am cooking three meals a day, planning home essentials, and exercising properly.

None of these needed much of my attention because either a school system guided me to follow a routine, or during work, I simply get things done in whichever easiest way (i.e., store-made food, ad-hoc workout classes). Right, I don't plan much about the daily routine.

If it costs you a little more but saves you time, why bother planning out the day? I used to think.

Grocery stores are the only place I visited routinely through the past two weeks for basic stuff: vegetables, meats, noddles, fruits, another bunch of cooking ingredients. It's almost a shame that I got excited about every little improvement that I made to my meal: if it tastes a bit better than last time, it fancies with truffle honey this time, or if I cooked the sunny-side-up just about right without burnt.

making progress with sunny side up:

I celebrated my 30-year birthday at home with self-cooked steaks. I was happy to see myself doing all these cooking gigs, feeling like I got the David Chang spirit after all. Oh, what a shame, I'm 30 years old and just started taking care of myself. I have to point out, WholeFoods expenses add up quickly, especially after I saw a couple in front of me paid $489 for groceries, wow!

Another thing that struck me for a couple of days was the classic joke of toilet paper rush. I wasn't part of it because I thought, what idiot would do that?

Toilet paper rush must be just a sarcastic meme - jokes on me.

A few days into Safer At Home order, I found myself standing in line at 7:45 am, waiting for WholeFoods to open, just trying to get some paper towels & toilet paper. They were all sold out, of course. However, the WholeFoods kept failing to deliver paper products in its Monday & Wednesday load (i.e., load means one shipment of products, and yes, I even learned the correct terminologies at WholeFoods), so I went there four mornings in a row.

Humans are fragile. I had firsthand experience, not even talking about the virus itself. With a bit of losing control, missing toilet paper, or skipping a meal, it gets me oddly uncomfortable. All of my so-called zombie apocalypse skillsets are not useful at all to this occasion just yet. It's an awkward state: I kept wondering if I shall be more cautious or if life is going to be just fine shortly after.

Luckily I have a place to stay and have family around during this hard time. There are more profound thoughts when I think of my past 30 years of life, but that's just too heavy to share, right? Wait, it's 5:39 pm, I need to prepare my dinner now :)

I wasn't appreciating physical materials as much, but now I'm so grateful for my surroundings more than ever. For every meal, I intend to prepare and eat without wasting; for every piece of paper, I attempt to reuse as much as possible. Oddly enough, COVID-19 forces me to rethink life: what if I were born in difficult time where even a piece of paper is luxury? what if there isn't enough of food for everyone anymore?

Without reflecting too much fear here, I just hope to live a bit more thoughtfully from now; appreciate what I have and share with those in need. I forgot to mention, a complete stranger helped us with new masks; that was, hmm…, pretty personal moment for me. Yeah, you get the point: appreciate what we have and try to help others. I'm going to stop right here; I already sound like my parents in the first week of my 30's : )

Fun Aspects of Event-Driven Architecture in Serverless

TuWang — Sat, 16 Nov 2019 07:43:20 +0000

Serverless architecture has its benefit of on-demand executions. By definition, 1) the service owner no longer needs to maintain an all-time-live server, 2) it replaces the long-standing server host with low-cost on-demand resources, 3) it only executes a job only when triggered to do so

There are a few key concepts that distinguish serverless architecture from traditional server architecture. For example, serverless architecture is event-driven, and its components are often stateless, etc.

This post will dive a little bit into event-driven serverless architecture in the context of building web service APIs in AWS.

Server API vs. Serverless API

Traditionally, regardless of what type of server you prefer, it listens on a port and handles HTTP requests. The serverless architecture removes the concept of the server (at least from the end consumers' perspective) and replaces it with an event-based job.

In the serverless world, servers are abstracted from users. Instead, it exposes event queue (i.e., SNS/SQS) to you and allows you to attach a job (i.e., lambda) to the event queue. The serverless infrastructure makes sure a message in the queue triggers one execution of the lambda.

Event Driven by Whom?

A unique but interesting challenge sooner will come into the picture: *who controls the event and how to scale? *

The trivial answer: the service consumer (your service client) controls how frequent the event will trigger, just like before, as to how the client calls your server APIs.

Yes, absolutely, with some nuances that make slight differences:

The traditional server typically restricts caller in agreed TPS, so the client needs to handle API throttle and retry
The serverless architecture allows the client to fire off the event messages and forget about it. Instead of throttling the client, the event processor carries more responsibilities to gracefully handle a large number of events/messages without losing the messages.

Not saying which way is better, but you should keep in mind the differences when choosing the service architecture.

Stateless

The traditional server provides APIs such that the client often manages the call sequence. For example, in the use case of running write commands, the client may want to 1) Save Post v1.0, 2) Save Post v1.1, 3) Save Post v1.2 during fast edits on Dev.to. The client needs to chain the sequence of saves, wait for the server to respond for one request, and finally fire off another save command.

In serverless architecture, you can still do the above, utilizing Lambda+APIGateway. However, for the fun of discussing event-driven use case, let's imagine we did the above with just events.

Here is the fun challenge: 3 events arrive in incorrect order v1.2, v1.0, v1.1 to the queue. The lambda is completely stateless so it won't care about which logical version to process first. Rather simply, the lambda processes the messages without caring for the sequence and will save the v1.1 incorrectly.

Of course, we do not want that.

To resolve the sequencing challenge, one might choose a data store to keep all of the draft versions. When a lambda spins up to process, it will look into the data store to look for the latest version and only save that one. After resolving the challenge, the UX appears the same to the end-user : )

There are other ways to solve the challenge for sure, but you get the point. Serverless architecture often indicates stateless components. If your service is highly dependent on states, you probably want to utilize a workflow engine to accomplish the tasks rather than only relying on lambda + SQS.

Conclusion

When you first think about serverless, it appears light and easy to use (it is!). However, it does come with its own set of new challenges that the traditional backend engineers may not face.

One last fun fact that I want to share: whatever name or wrapper we want to call it, serverless is nothing but a new coat on top of the traditional server architecture. Yes, believe or not, old-fashioned hard-core infrastructure engineers are still building traditional servers to host all the serverless components mentioned above(lambda, SNS, SQS). Don't treat serverless as some dark magic : )

Same applies to internet vs. cloud. You get my point :)

Team Dynamics: Engineering Focused v.s. Management Focused

TuWang — Fri, 25 Oct 2019 21:01:25 +0000

Which team dynamics do you enjoy most? I prefer engineering-focused dynamics because, well, I am a software engineer. However, I have seen teams that are entirely management-focused.

Two Types of DEV teams

Engineering-focused Team

Decisions are driven and often made by engineers
Team's success is also evaluated at engineers' happiness level
Manager's goal is to keep the team happy so people will be productive

Management-focused Team

Decisions are driven and often influenced by managers
Team's success is also evaluated at the manager's performance in front of higher leaders
Engineers' goal is to keep the manager happy, so they keep a pleasant team dynamics

Why the Conflict?

Both engineers and managers are aiming for the same goal to launch services. How come the conflict?

Engineers and managers have different mindsets at work. Engineers want to keep building, preferably new services. Managers want to launch new services, but they are also worried about the overall health of all their services. To accommodate both parties, engineers and managers collaborate through a sophisticated process: reporting.

Reports come in forms of project status, service metrics, business metrics, sprint retrospective, etc.

For engineers, the necessary amount of metrics and system progress tracking is sufficient to keep the project running and hit the launch goal.

For managers, they are demanded to report to their leaders (who has less context of leaf teams' work) about the overall health of projects.

There comes the complication: 1) engineering metrics are specific and scattered while managers want summarized reports, 2) Each manager has a slightly different priority in terms of business metrics, that creates their particular report taste.

As a result, managers influence engineers to conduct business reporting processes. I do believe it is a necessary act to keep the team healthy.

In the end, it is the art of keeping balance, again (it feels like anything at work comes to talking about balance). Or, in reality, it depends on your team has a super-driven manager or an oddly-aggressive but respected engineer.

Pros/Cons

Let's talk just slightly about the pros and cons of the two styles.

Engineering-focused Team

Pros:
- Happy Engineer, Happy Life
- Engineers make decisions efficiently because they are close to the actual technical components
- Pleasant dynamics attracts talents
Cons:
- Engineers get spoiled which may decrease team efficiency
- Engineers may only see problems at contained scope rather than the overall roadmap

Management-focused Team

Pros:
- Manager can help the team with the larger picture
- Engineer are working towards a relatively united team vision instead of battling against each others' vision.
Cons:
- Keeping the manager happy could cause tension in the team dynamics, because other engineers may not agree with the manager's tech preference
- The team's success is reflected by the manager's success, which dissolves the value of success for team members
- Engineers may create processes or spend hours trying to summarize things for the manager, but this does not bring direct value to the team

The Mix

In some companies, people manager and tech manager are two separate roles. The tech manager influences the technical aspects of the team. She or he perhaps also write code. The people manager, on the other hand, can be active on multiple teams but does not influence technical decisions as much.

What do you think is best for your team?

Discussion: What is Your Favorite Serverless Architecture?

TuWang — Sat, 19 Oct 2019 09:12:41 +0000

In the last year of the decade, I found myself working closely with the entire service stack. I became familiar with a few technologies in AWS serverless architecture:

I use CloudFormation to manage 99.9% of my resources
I use standard storages like S3, DynamoDB
I utilize message systems to deliver events
I use API gateway and lambda to build the APIs

What is your favorite Serverless architecture? What are the excellent examples and pitfalls you have experienced? Happy to learn and discuss!

Discussion: Is a Running a Massive Project equivalent to Running a Company

TuWang — Wed, 16 Oct 2019 04:57:49 +0000

As a software engineer, I have helped to manage the lifecycle of projects (i.e., design, implementation, testing and launch). I have also observed different roles (i.e., management, engineering, product) working on multiple projects. I realize that a project of organization-wide impact pushes all these project members to progress in their career (and some of them become org leaders)

I had a few related questions:

In an enterprise environment, is running a massive project equavalent to running a company?
How large should this project be to give an individual the amount of pressure and experience of running a company?
If you think "just quit your job and start a company", why do smart people still tend to stay at enterprise company?

I have started small business before, but it was never close to a startup. I want to know how people think of this topic, given our common experience of the past 10-20 years of tech industry growth.

Let me know your thoughts, and I'll draft my own thoughts in comment area too.

6 Tips to Succeed in Code Review as a New-hire (w/o being bashed)

TuWang — Sun, 13 Oct 2019 18:54:37 +0000

As a new-hire, it isn't always easy to adjust to the norm of the team.

Socially, people are usually friendly at the workplace, so you control the dynamics about how much you like to blend in. However, when it comes to code review, your friendly neighbor may bash on you repeatedly.

Why? Code convention matters and code quality is the key to keeping everyone's job.

I have six tips to help you catch up to the new team without being bashed.

1. Honor the context and lower your pride

If you are new to software engineering, then jump to the next section. Don't even think about pride. 😉

You may have years of working experience, but please, please be humble. None of your experience matters if you don't know the context.

A solid example of an argument from a new-hire. The claim was:

There must be a service-specific interface when integrating/calling a dependency service.
Reason: the external dependency service can change, but in our code, callers of the interface can stay w/o changes.

Code becomes like this:

public MetadataService implements MetadataServiceInterface{}
public PublishingService implements PublishingServiceInterface{}
public AService implements AServiceInterface{}
public BService implements BServiceInterface{}
... //10 more services like this

By looking at the statement, it sounds entirely correct. Yes, loose coupling from the dependency integration is a good engineering practice.

However, the good intention brings almost no value in our team's context: there is no need for decoupling.

Unfortunately, the dependency services are not simple CRUD APIs. We cannot replace them.
By design, the way (i.e., high-level workflow and business logic) we utilize these APIs in our code has already strongly coupled with the specific services.
There is only one implementation of each service integration in the long term.
If we do change a dependency, the business logic will be affected inevitably.
Good intention practices like this will fail to achieve the very close launch dates, especially requiring changes to everything in our code base. The change will cause days of interruptive merging on multiple engineers' branches and unit test changes.

I am not saying these rejection comments are necessarily correct or conduct best engineering practice. The reality is, a team needs to produce, and we cannot delay the launch. One of the best qualities of software engineering is to take calculated risks, so you have to learn the context.

2. Read your team's code reviews

Afraid of making mistakes? Just learn from others' problems. You can very quickly figure out the common nit-picking issues, the concerning code structure, and the error handling practices.

You can also observe good practices as well. Find out who are the best engineers on the team and look at their code.

I'm not saying that you should follow what others do without critical thinking, but at least understand the dynamics. Don't make the same mistakes that others have made.

3. Leverage code convention wiki

If your new team already has a code convention wiki, that's amazing. You'll learn fast about what to do and not.

If your team does not have a code convention wiki, it's time to build one : )

I like to take notes of things that I learned and put them into a wiki. Remember all the mistakes and adjustments you read in others' code reviews? Document these in a wiki so everyone can learn.

Documenting code convention does not give you authority, but it groups you and the others under the same umbrella. You are contributing in a non-intrusive way, that always brings allies.

4. Start with a small code change

Regardless if you are junior or senior engineers, we both know that you want to prove yourself through code.

Posting a massive code review does not prove you are a reliable engineer.

Presumably, you can write a long piece of functional code without issues. But again, you do not know the norms on the team yet, and the massive amount of code draws a large target for code critics. Your code may not be necessarily wrong, but the nitpicking comments are just noise to slow you down.

It will become worse when: EngineerA supported your practice a year ago, and now he raises his argument again towards EngineerB for leading opposite practice. Your code review will become a battlefield.

Nah, please conduct a small change at a time, or break down your code change into smaller pieces.

5. Never make the same mistake

Let's say you have 1) read others' code reviews 2) finished the convention wiki 3) received feedbacks on your initial code reviews.

Make sure to note down all the mistakes you are aware of and avoid the same mistakes!

For example, in my world, common nitpickings are like:

OMG don't ever go over 100 lines for a function!

20 public String functionA(...) {
21 ...
22 ...
.. ...
150
151 }

Indentation matters, break your function parameters into multiple lines for readability

// don't
public String functionB(String param1, ServiceA param2, ServiceB param3, ServiceC param4, ServiceD param5) {}
// do
public String functionB(String param1,
                        ServiceA param2,
                        ServiceB param3,
                        ServiceC param4,
                        ServiceD param5)
{
    ...
}

You can avoid nits like these utilizing documentations. Don't make the same common mistake in your code review.

6. Earn trust before recommending a design change

Sure, we all have opinions.

I'd take 4-6 months to fully adjust to a team's coding dynamics before I push for design recommendations.

Your opinion matters, but to convince your peers, you have to earn their trust. Your team needs enough time to know you before they trust you with a significant code change.

Conclusion

If you forget everything above, take these away: 1) Learn the context, 2) Read the code, 3) Leverage code convention wiki, 4) Small steps, 5) Don't make the same mistake, 6) Earn trust before you thrive.

Happy learning!

Retrospective on Our Introvert Engineering Personality

TuWang — Sun, 13 Oct 2019 05:45:20 +0000

Guilty Charged

It happens all the time on social occasions: a talkative individual is leading the conversation, and I can quietly curl back and watch like a cat. People are friendly most times, so that they won't bother me. They may remember me as a quiet person, not having much to share, and probably just too shy. Perhaps they think I am on the other side of the fence in the zoo : )

Stereotype

Lots of engineers like to express them through writing (like what I am doing now), or perhaps through code, diagrams, or flow charts. We spend a tremendous amount of time conducting intellectual tasks quietly, which inevitably builds into our stereotype, an introvert personality.

Frankly, being quiet on social occasions is a kind of privilege I get nowadays: there is no expectation. It allows my unexpected jokes to crack people up, which is incredible.

Other times, I dislike engineer stereotypes. It must happen to you before as well. A friend wants to start a conversation, but he has no idea what I am doing as a software engineer. His maximum efforts result in a question: 'what video game do you play now?' but he has absolutely zero interest in anything you say in the next second.

Well, I'm not angry. I get it. I don't talk much when we meet, and you have no clue about engineering, so I must be into games since I am a computer scientist.

Unfortunately, no games for me anymore. All my engineering friends and I am busy building apps, making your (as an end customer) life slightly better each day.

Extrovert Side of US

An introvert personality leads people to imagine that the quiet person must love video games or live like a cat because he is not confident to face the world.

It's all about context.

In the right context, engineers love to argue and talk.

I can talk to you about a new algorithm problem for one hour straight. We can discuss the data structure to pick and the options to solve it, as long as you don't fall asleep in the first 2 minutes.

Lots of quiet engineers are rather super extrovert when it comes to the right context:

In design reviews, engineers debate around technology, workflow, risk analysis, impact to dependencies, and many other aspects with clear thought. We do not back down much in these discussions because we are trying to express the right thing to do in different scenarios. It's especially fascinating to observe multiple relentless senior/principle engineers debate because you can learn so much out of a single meeting.
In coffee chats or lunch breaks, engineers love to pick on the little things they see on the street and reason about how things work?. For a week, I kept telling my friends how much can the taco truck family make in a month, and that's perhaps a lot more than our average salary. Other times, we talk about how practical and possibly how much money do we need to make it to Mars one day. Well, if we can enhance our organs to sustain many more years.
Finally, in writings, engineers are super expressive and have the abilities to put complex engineer spaghettis on paper. I admit design documents have less to do with extrovert personalities. Though, frequently, you can discover awesome & crazy ideas through technical documents that blow your mind.

Can We Break out of The Comfort Zone?

I believe the chance is high. It may sound narcissistic, but like it or not, engineers are impacting every corner of the world. We do have a say in many ways, if not too passive through code.

If you are like me, who does hope to speak to a small group of audience and deliver clear thoughts, perhaps some training is needed. Public speaking is not a straightforward battle. You need to rally with the fear, control the body language, and meanwhile pay attention to the audience's feedback.

I generally do a few things when I am arranging an important meeting or have to speak in front of an audience:

I am an expert on my subjects. If I go fast on speech, none of you could ever catch up, so I will keep it slow to make sure you can follow. That is, imagine the audience is average intelligent who needs guidance. During your show, your audience does not outsmart you in any way.
Save these people from their boring conversations. When I don't speak, I do pay attention to people's topics. I have a true story in a public accounting firm internship. I was a tech intern, but I still had to stand among a group of interns who were talking about sports at the company event. I knew it from the beginning that none of these nerds care about sports. They perhaps all just worried about what happens next after the internship ends. I needed to do something. I saved these people, literally, from the boring sports/weather conversations by putting in a friendly interruption about movies, ice cream shops, or something. These are interns (I was as well) pretending to be experienced professionals.
Make it not about your self but the group/community. Even for a popular character, if all the individual talks about is about her/himself, no one will care over a minute. If you do prepare for a social occasion, bring up topics that are relevant to the group. It's a bonus when you also state your own opinion.

The list can go on. I honestly believe an introvert personality can be our advantage. Calm down and embrace your introvert smart mind 😬

When Will I Suffer Career Crisis as a Software Engineer?

TuWang — Thu, 10 Oct 2019 06:32:36 +0000

(before you read, no need to panic. I write the entire page with a smile on my face because I supply antidote in the end 😛)

This has been bothering me ever since I picked my computer science major. The fear evolved significantly through my last job: I observed the conservative elders' trying everything to secure a safe retirement.

I have empathy for them: we humans eventually will all be at the stage where we can not think as fast nor produce as much such that we simply want to stay in comfort.

Admit it or not, being a software engineer, the fear of becoming insufficient is especially severe. The question is: when?

Problem

(part of the fear is caused by the jump from $100k/year to $0, but let's save that topic)

If I were a sufficient 25-year-old software engineer in 1995 working on Windows 95 applications: by the age of 50 (the year 2020), none of my skills in the early days are relevant today and I am perhaps out of job by now.

You may argue that a software engineer should have adapted to the changes, or he may have already switched to a management role.

However, embracing changes is a bit against human nature. I believe humans naturally want to be part of a stable environment (i.e. home). Frankly, most jobs do not demand such quality, unlike software engineering.

If you are not adaptive and still choose to stay as a software engineer, you are doomed to face a career crisis but unfortunately much earlier than anticipated.

History

By design, software engineering is ever-changing. It is a sophisticated line of career since its creation, demanding a dedicated mind to solve programming puzzles.

Despite our pride in being an engineer, software engineering has only 70-80 years of history since the first digital computer appeared in the early 1940s. Personally, my narrow definition of modern software (that I ever touched first as a child) has only 25 years of history since the Microsoft Windows 95.

Regardless of perspectives, none of the software created in the 40's or 90's matters anymore today. Software development boosts throughout human history and we, software engineers, are on the edge of being the history.

10 years ago in 2009, AngularJS was just appearing alone with NodeJS, when React was not even a thing. Now React has already taken over the world, while the sexy graphql is trending over rest.

Take a breath if you are a backend software engineer who loves working in the comfort backyard supporting Java/Tomcat web apps: the last 10 years must be a roller coaster for you.

Take another breath if you are a new grad. The familiar tech stack that led you into computer science may no longer be trending in the industry. Surprise!? Welcome to the golden era of software engineering.

When and How?

The career crisis will happen much earlier than your age agrees, if you: 1) stay as a software engineer, 2) stop learning new tricks.

My grandmother worked for many years as a mechanical engineer at a car factory until she retired. Fortunately, she didn't face drastic technology turbulence in her career. My parents has been in construction engineering business through their career. Their tools have been getting better, fortunately, they didn't need to adapt to drastic product change neither. Oddly, despite how much more prepared academically, I am the first generation in the family to experience a career full of changes.

My generation of (software) engineers are facing extraordinary challenges: when we stop changing, unlike our predecessors we will fail miserably.

It will take 6-12 months to be completely left-behind by front-end tech stack, and perhaps 12-24 months to be out of sync with what modern backend tech stack offers.

Action?

A. Being adaptive

It is trivial but time-consuming to do. It does not matter how hard we try, our current skills inevitably are becoming irrelevant.

How to keep up? Beat the cycle as much as possible:

frontend engineer: perhaps try to set up personal retrospective sessions to go over front-end technology on monthly basis. Check out what's new out there and do a POC once a while.
backend engineer: in my opinion, the changes in backend technology is relatively less, but when it happens it's usually evolutionary. Think out of the box for once: look into Node if you are Java only before; look into serverless if you are server only previously.

With regular retrospectives, I sometimes find myself appreciating new stuff much easier than if I were forced to learn new tricks for a job.

B. Drop it

There is always a PlanB.

A dramatic twist in the career may not be all that bad. You can switch to non-tech roles: people manager, product manager or some role completely different. Hopefully, you will finally realize how much you love the new role over software engineering :)

I have not switched roles before so I can't comment on how great any direction might be. One thing that I believe: do it if you genuinely like it, but don't do it because you are just running away from other problems. (same applies to a new relationship)

Last Two Cents

If you can, experience a career crisis early on, hopefully, a small piece at a time so that you can calibrate your life around it.

Don't wait till 2020 to find out you and Window 95 are both histories.