Hello senior engineers, what does a mid level frontend engineer need to know to be confident in design discussions across stacks?
Posted by asmita97@reddit | ExperiencedDevs | View on Reddit | 20 comments
Hi folks, hope you all are doing well!
I have been working at my current company for 5 years now, and it was my first job straight out of college. I am primarily a frontend engineer, who enjoys frontend but does have aspirations to atleast be educated and somewhat aware of backend.
Lately i have been feeling that when it comes to having “opinions” about what design should we have for a problem statement, I am not very good at giving a bunch of options.
Earlier this problem was only with frontend part of the problem statement, but as i have hit the 5 yoe mark, it is expected out of me to drive projects end to end, which means being somewhat aware of backend, and have some opinions and sense of how the HLD of application should look like.
So i have 2 questions 1. How can i go from being a developer, to a frontend “engineer”, one who is able to think multiple approaches and understand how to scale and design the frontend part ? What resources i need to check here? And any tips on other things to do to build awareness?
- What backend engineering concepts should i know as an Frontend engineer, so that I am not totally clueless about the backend part of application, and can have opinions and suggestions for overall HLD?
Sorry for the long post, but I would love some actionable advice. Thanks in advance.
eyes-are-fading-blue@reddit
Don’t you have a mentor? Someone should have told you some best practices, what to look for, how to be future proof or when not to be future proof. You combine that with some conventional wisdom from books and other sources.
Wide-Pop6050@reddit
You need to understand the business and the use case well. One thing that stands out is people who can determine what the end user impact will be and what will change and what is important vs. not
Awric@reddit
Whenever I suggest multiple technical approaches on the front end side of things, it’s often because there are valid reasons against each approach, and we need to discuss as a team why an approach should be ruled out or selected. Should an input form’s placeholder text come from an API request or should it be on the form itself? Does it require context that comes from a service, i.e. does it have anything that depends on data specific to the current user? Is it important for there to be offline support?
In the above example I’m just going through a simple case, but I’m thinking about the complexities of involving backend with frontend and whether it’s worth the effort. Sometimes it is, sometimes it isn’t. The decision often requires input from the product manager
PPatBoyd@reddit
Can you give an example situation that you found particularly vexing?
All of software is tradeoffs between different ways to accomplish the same goal, but I find frontend brings out the widest opinionated behaviors that get people feeling defensive when challenged. "Strong Opinions Loosely Held" is a good mark to stand by when judging where to invest your time.
Experience is the key to confidence; go build things. If you aren't sure about something, develop your ability to compartmentalize concerns and know which requirements you have concrete solutions for separate from the ones you're not sure about and need prototyping, investigation, or area experts. Being able to efficiently communicate the gap between solved problems that are JustWork™️ and the hottest problem areas / net-new work in a way that is clear with an estimated plans is how you build the confidence others have in you.
asmita97@reddit (OP)
Thankyou for your reply! To answer your question, the situation that I mostly find challenging in my day to day work is 1. Knowing atleast one more way to solve a problem. Usually the solutions that come to me are always the most obvious ones, but i am struggling to see beyond obvious and find alternative architecture.
PPatBoyd@reddit
I'm reading (1) through two lenses; the patterns you aren't familiar with and the requirements/tradeoffs you aren't acknowledging. For the former there's not much to do except read and try things -- and allow the team collaboration to happen, you don't need to come up with multiple solutions on your own. For the latter, the tradeoffs and needs you aren't seeing, it's about observing where the pressure or tightness is in the system. It's hard to type quickly about abstract examples but the simplest that comes to mind is the difference between "opinionated" components and unopinionated ones. Unopinionated components take more work/overhead/support to use, opinionated components give more consistency but box you in over time with their rigidity.
(2) For me I think about understanding the flow of the system and where the pressure is, and about [API] contracts. Start from your requirements and game out the intended experience. Sometimes it's about thinking about different concerns that aren't the happy path, e.g. what are the security or privacy implications of a given solution? What happens when a network is shaky? Or the data outside of your norm? For your specific example it's about establishing the contract between the front and back end, where the back end needs to maintain compatibility with the front end as changes in requirements occur and the front end needs to avoid making availability assumptions about the back end.
asmita97@reddit (OP)
Thanks a lot! This was super helpful and insightful 😇
greensodacan@reddit
Also a primarily from-end engineer, \~15 yoe. When you say "front-end", what industry are you working in?
All of the classic fundamentals apply. Data structures and algorithms aren't as important, but you do need to be familiar with object oriented and functional design patterns. You'll also want to understand state machines and event driven architecture.
For getting started, I suggest reading "Clean Code", "Design Patterns", "Clean Architecture", and "Code Complete". You'll need to look beyond the implementation details of a solution, and at the "why".
Using the web as an example, why is React so popular? (It's not just trendy.) Why do SPAs keep proliferating given how vocal the community is about hating them? Why are so many dynamically typed languages adopting tools to enforce type safety?
asmita97@reddit (OP)
Hi! Thanks for your reply! I am working on a CRM tool in the support vertical of my company. But im flexible to changing domain. And your advice is golden! I will start with the resources you mentioned and come back with what i learned 😇
TwisterK@reddit
in short: try to build from front end to backend by urself during a relaxing weekend for a hobby project, I can ensure u will learn so much more than listen to us telling what to do.
Far_Archer_4234@reddit
Confidence and competence are independent of one another. The answer to your question is "none". Take Nike's advice.
DeterminedQuokka@reddit
Are you talking about like what the front end looks like? Or like what servers we should build?
If it’s around what the front end should look like learn about ux. There is a great book called don’t make me think. You want to talk about the users experience. The tech only matters if it is a blocker to the user experience.
If you mean system architecture you need to know the parts you touch. So you don’t need to have an opinion on if the server you aren’t writing is in Java or Python. In fact you shouldn’t it’s not your business.
You could have opinions on the latency with which things return from that server. So like to hit the appropriate page quality for Google you need the largest paint before whatever time. (I’m a backend engineer so I don’t know this number I ask my front end engineers for it).
You should have an opinion about what information you need in APIs and how you are going to use it.
You should have an opinion about how you are projecting user privacy given that you might have api keys and stuff in the front end.
No-Economics-8239@reddit
Real life doesn't really have a check list of requirements you need to learn to level up. Every job and situation is different. Technologies change. Fads happen. What things are the best are subjective and difficult to prioritize without a lot of context.
In general, the things that have served me best throughout my carer is my curiosity and interest in solving problems. I don't just accept things as status quo. I ask why a lot. Sometimes too much. Which can be annoying, but can sometimes uncover issues that others have dismissed as too complex or systemic to try and look into let alone fix. And then I fixed them. Or, at the least, find ways to make things better.
Incremental improvement is a superpower. You don't need to level up all at once or in leaps and bounds. You do it gradually over time. Some of it will hopefully be things of interest to you, that you look into because you want to learn and want to know how things work. Some of it will ideally be valuable to your current and prospective employer and help keep you current and valuable in changing job markets. And some of it will just be buzz word bingo. Either to round out your resume, or else to give you a broader or deeper perspective that you can't get when you focus on specific things for too long.
To your specific questions, scalability and architecture are important design considerations, but not ones that typically limit general coding projects. One working solution is largely the same as the next as long as you have a nominal problem set and aren't trying to deploy to a global market. And the people who really do get experience working at that scale are pretty limited. And they tend to be the experts on the topic, so looking at the stuff published by them often gives you the best we have available in terms of good design and cautionary tales.
And branching out from your current work is on you. Either by getting approval from your managers to work on or learn something new. Or is something your pursue in secret or on your own time. Which means a combination of taking advantages of opportunities when they arise, and making your own opportunities when possible. Even so, specialization can still be useful. But it typically needs to be coupled with broader perspectives. When you can gain just by working with and talking with people who are working on things related to but different than what you are working on. Who are your partner teams? Who are your peers and compatriots on those teams? Refine your soft skills and build those relationships. You don't have to work directly on something new to gain insights from people who have them to share. You just have to give them a reason to do so.
Independent_Fan428@reddit
I’m really interested in this. What do you consider deploying to a global market? Any recommendations on folks to investigate?
No-Economics-8239@reddit
People often think they will open the flood gates and the world will beat a path to our website or application. That's not what typically happens. For most of us, we just buy the cloud compute we need. As you scale up, you turn the tap to buy more compute time as needed. Getting traffic is the problem you're trying to solve, not scaling. For the unlucky few, they slashdotted off the board due to a surge of initial interest they aren't prepared for, and then have to try and claw back those customers by trying to solve the problem overnight.
But the true behemoths operate at a completely different scale and logistics. And many of them publish their own white papers, introduction docs, and technical books.
https://cloud.google.com/blog/products/networking/network-distributed-applications-at-global-scale/
oVtcovOgwUP0j5sMQx2F@reddit
Know about general API design patterns and learn about the specific data access patterns of your frontend
chillermane@reddit
Honestly it’s pretty hard to make meaningful design decisions as a front end only engineer. Front end is not really that “deep”, you can basically be a master of it in like 2 years or less. You can pretty much take any approach and it’ll work out fine as long as you avoid doing really dumb stuff.
I would personally recommend just figuring out how to become fullstack. You are going to be very limited in what you can contribute if you only know front end (although great front end devs are very valuable, all they can really do is generate working front end code). It’s really hard to know how to design things properly if you aren’t competent in the whole stack
FinestObligations@reddit
How to tell someone is bad at frontend development without them saying they are bad at frontend development.
snuggly_beowulf@reddit
You can not possibly be series. Did you forget the /s?
kevin074@reddit
you can look up frontend system design on youtube or find resources on reddit and go from there.
the unfortunate thing is that frontend system design is still a relatively new concept, so there is no consistent flow to how one would go about the design, what concepts to cover, and to what level of detail; I have seen a "great" design resource literally was just a lecture about very domain specific knowledge and that is not helpful for interview. However, seeing how others conceptualize the problem would nevertheless be helpful. You'd also learn a lot about different niche techniques that will inevitably get you brownie points here and there.
Personally I think real world frontend design mostly should be done with wireframes, so that engineers, designers, and PM can have consensus on how the app should behave. Luckily usually the designer come up with the wireframes, you can use it as a source of truth, and add your technical notes on it. Furthermore you should develop some sort of list on what things need to be checked off for feature implementation (a lot of aforementioned resources have such list implicitly).
the point of the design is so that stakeholders can have high and mid level understanding how the implementation should be. The wireframes get you the high level and your notes/lists would provide the mid level understanding, and you as the developer or part of the team can discuss about low level details among yourselves (or via code review).