Hello everyone, I landed a senior frontend engineer positon at a good company and was wondering if you had any tips for me. I've never really worked as an employee and have spent over a decade as a consultant, so any tip is really appreciated.
In addition to what <i>chadash</i> said, and the whole "Chesterton's Fence" avoidance... I'd say being helpful to the team goes a long way. Here's an index reply I wrote that I link to often[0]. The first link there is about understanding codebases, but if you look at the links, they're pretty much all about making the team's job easier, removing frictions.<p>You have a useful background in consulting. As any good consultant, you observe, you recognize problems and frustrations, you figure out the job to be done, you figure out the current state and the desired state, you represent that gap, and you solve that problem. You do that for the team. You're hopefully accustomed to communicating with stakeholders with different skillsets and doing impedance matching: this is valuable. Make engineering problems understandable by non-engineers, make non-engineering problems understandable by engineers. That transcoding is very useful.<p>If your team is having trouble deploying something, make deployment easier. If code is not documented, write better documentation. If issues lack clarity, write good issue templates to capture <i>problems</i> (and not implementations/solutions) and lower the barrier to writing clear issues. If you can bring your expertise in consulting being exposed to a variety of contexts, sectors, and industries; this is useful. These are examples that may not be applicable, but you get the idea: there are a lot of things to do that have not been done for a bunch of reasons, be a gift of a person and be helpful.<p>- [0]: <a href="https://news.ycombinator.com/item?id=25025253" rel="nofollow">https://news.ycombinator.com/item?id=25025253</a>
Focus on making your code consistent with the existing style. Don't make big changes to code bases when you first see them, no matter how much better you think you can make it. There's nothing worse than a new dev who <i>thinks</i> they know better messing up code by trying to do refactors in their first week on the job. Don't suggest big changes to processes until you really understand current ones. After you've been there a few months and really understand the codebase, by all means, refactor away and make suggestions for other improvements.