|
Is there a list of things you'd say a frontend lead has know? I more or less fell into the role about 6 months ago and have been mostly making it up as I go along. I'm originally a Java dev that added Angular in the last few years to be able to call myself fullstack. Now I'm asking myself if it's normal that the frontend seems to be on fire all the time, also why are my devs getting excited about semantic HTML and CSS? It was mostly fine but now we're staring down a potential migration away from Angular Material to an internal design system and it's honestly quite scary. Unfortunately the previous devs built the frontend in a couple of months to hit a deadline. They succeeded, but also built up a lot of tech debt, among them misusing Material, that is now causing major slowdowns. So we need to change this to keep up our development speed but I have no experience in migration whole UIs. I'm worried this is going take away too much from the features we need to deliver to actually keep the project alive. But at the same time approaching this in small steps also seems difficult because you don't want to annoy your enterprise customers by moving one UI element every two weeks.
|
#
¿
Mar 4, 2024 23:38
|
|
|
|
| # ¿ May 14, 2024 10:50 |
|
|
lifg posted:It’s easy to give a list of technologies and ideas a front end dev should know, but I don’t think any of them would solve what appears to be your company’s organizational issues. I'm probably mixing up two points, the important here was, OK, what am I missing to be able to judge what I'm being told? So, when someone tells me that semantic html and separating HTML, CSS and JS is the key, I'm not sure. Is there some foundational web knowledge I should be reading up on? Especially after I watched the same person just today make a giant mess in a straightforward pullrequest. And, well, the organization is sadly not extraordinary, no paying customer is a fan of "come back in a couple of months when we're done rebuilding the application".
|
|
#
¿
Mar 5, 2024 18:46
|
|
|
pokeyman posted:You might be able to migrate incrementally if you can embed the new framework within the old? Like pick out a small view at the bottom of the view hierarchy and swap it over, bridging whatever bindings and events from old to new. Then you can replace all the lowest hanging fruit, then slowly work your way up the view hierarchy. It's ok if it takes weeks or months because the whole time you're maintaining a working whole, and you don't need to stop everything while you rewrite. We're currently looking at this, one problem is the changed look and feel. Is it better to rip off the bandaid in on go and replace everything? Or will users accept the ongoing disruption? In an enterprise setting we have very few customers, so we can't really afford annoying them too much. We are also considering cleaning up the rest of the HTML layout mess first and then leave the components for later which is as close to working in steps we're probably going to get. I have migrated backends hidden behind APIs before but this feels different because our users can pretty much see every little change as it gets released.
|
|
#
¿
Mar 5, 2024 18:54
|
|
|
LLSix posted:Pokeyman's advice is good. lifg, pokeyman and LLSix, thank you very much. I'm probably overestimating how much difference it makes to have every change as visible as this. I'm still remembering the trouble in a past project when all we did was move a button a little bit to the left. From the user phone calls we got you'd think we rewrote the application in pink and blinking comic sans. Also, it probably doesn't help that I have actual Aspergers and am feeling a bit overwhelmed with the still new frontend lead job. Hence me asking if I missed something important, wouldn't be the first time. I've got some vacation scheduled, which should help, I just didn't want to leave my junior devs without support while all my seniors devs were gone.
|
|
#
¿
Mar 5, 2024 19:30
|
|
|
lifg posted:Yeah, there’s some core stuff in your question. Yes, that's it. I'm noticing that I have much more Angular than general frontend knowledge, so judging how much I need to have more of is difficult. I have been improving, so a clean grid is no problem, same with taking an example an applying to my layout. But please don't ask me to list every CSS selector or when precisely to use <section> without access to MDN. So, if one of my devs starts exclaiming the virtues of semantic and working without a framework, I'm asking myself why we can't keep everything organized in Angular components and compose those.
|
|
#
¿
Mar 5, 2024 20:07
|
|
|
I'm currently collecting the different approaches to our actual problem, which is that the project has a mess of adhoc UI solutions and no clear system, and not that we're not using the fancy internal system. This should help document the problem, assumptions and pros and cons and then lead to a solution as well as introduce some needed rigor to our architecture. I used something like this before and it helped, both to organize my thoughts, as well as revisit the solution six months later when some assumptions turned out to be not quite so valid as we thought. Talking to my colleagues, not doing a migration to an unknown and maybe not quite mature system seems to be gaining traction, maybe for obvious reasons, maybe because I've been radiating uncertainty. We'd rather clean up what we have first, even if it means our designer has to do more work to extract some sanity from our current chaos. That's at least something.
|
|
#
¿
Mar 5, 2024 22:11
|
|
|
Artemis J Brassnuts posted:I recently got promoted to lead but also wouldn’t mind getting a full-time remote gig. Have any of you done lead-type things while remote? I worry that it will be hard to keep the team feeling like a team. I'm in the same situation and, as you might be able to guess, not the best person to offer advice, but what worked for me is lots of 1:1 conversations, a shared teams channel and, once a week, an informal meeting. This seems to keep morale somewhat high, just be warned that it can be exhausting if you're like me. High quality documentation and automatic checks can also answer a lot of questions directly. It also depends on your team members, having generelly good natured and compatible team members helps a lot. Also, as I'm learning, small, focused tasks are really important to prevent team members from going awol for weeks and then delivering something wild.
|
|
#
¿
Mar 6, 2024 14:01
|
|
|
|
| # ¿ May 14, 2024 10:50 |
|
|
Artemis J Brassnuts posted:Thank you all for the remote lead advice! It’s encouraging to hear some success stories to offset my apprehension. I’m not sure if you counting me as a success story. I agree however, that public praise is definitely something we don’t see often enough, plus it also feels good to give, so don’t underestimate it. So, maybe as a follow up question to the thread, how do you manage your energy and availability? My team is in high spirits, but lately it feels like I’m burning my own sanity for this. I would like to be able to say, ok, today I just want to code to regenerate but there’s a, probably self inflicted, pressure to be available. In my case, my particular version of being autistic really doesn’t help. So, Artemis, try to take care of yourself better than I do for myself 
|
|
#
¿
Mar 6, 2024 17:25
|
|