| This is just my very personal and subjective experience, which may or may not apply to your working environment since I've no idea how many developers or teams you have or how your responsibilities are defined. This is at least what I've learnt so far in my environment: - Be transparent about your decisions, motivations and opinions. People will come to you for advice or suggestions for what to do, and if they don't understand your thought process that causes unnecessary friction. - Document everything in writing publicly (except confidential/sensitive info, naturally) - decisions, designs, ideas, proof-of-concepts. This will be helpful both to your fellow engineers since they can access this information on their own without you having to explain it to them every time they ask, and also helpful to you to recall the context in which you did something. I find myself often going back to notes I wrote months or even weeks ago, to remind myself of e.g. the motivation for why a decision was taken. Having it public also forces you to write in a clear, structured and professional manner since you're writing for a broader audience. - In terms of studying, formulate a vision for where you think your software should be within 1, 2 or 3 years, and spend time researching what options can take you there, learning how they work, and so on. I've found InfoQ to be a pretty good resource for keeping tabs on what others are doing in the field. - Be patient. Be prepared to repeat yourself multiple times, sometimes to different people, sometimes to the same people. Be prepared to communicate a lot, and keep in mind to tailor your message depending on who you're communicating with. - Learn to let go of details. You will see code and solutions pushed out that you perhaps don't fully agree with. Take a step back and consider if it's really that important or if it's good enough. If something gets pushed that really isn't up-to-par, be humble and consider that you might not have communicated the requirements clearly enough. - Make sure to understand the business side of the company, and always take that perspective into account when making decisions. You might from a technical perspective think a piece of software is in desperate need of refactoring, but from a business value perspective it might not make any sense. Be sure that you agree yourself with those kinds of decisions (i.e. don't blame "the business") because you'll likely find yourself having to explain and champion them to others who disagree with them. - I realized now that all of the above is mostly "soft skills" and have very little to do with technical skills or training. Which I suppose is the biggest learning I've had so far - for me the biggest gap by far was (and still is) mostly about communicating, working with others, and taking the broader needs of the company into account and not just the technical aspects. Just my 2c - hope it can be helpful to someone. |