# be an idiot that moves despite what I'd like to think, I believe software engineering is a career where technical ability can sometimes compensate for shortcomings in interpersonal skills. someone who is particularly strong technically may still find opportunities, even if collaborating with others doesn't come naturally to them. but there's a distinction between being technically capable and being effective in a team. technical expertise can open doors, but how you work with others will influence how far you can go once you're through them. with the current state of the hiring market, it can be even more difficult to stand out from the applicant crowd. being easy to work with is definitely valuable, but hiring decisions aren't always made on that basis. when there's an immediate technical gap to fill, someone with deeper experience may offer an employer something they're willing to prioritise: speed. there's a difference, however, between getting your foot in the door and succeeding once you're there. technical expertise might get you hired, but it doesn't necessarily determine how far you can go. the phrase, "an idiot in motion goes further than a genius at rest," is a popular motivational proverb which means that consistent action and execution beat overthinking, perfectionism, or unapplied intelligence. it's reassuring, but what the phrase leaves out is that geniuses can be in motion too. the state of motion in question isn't exclusive to idiots. geniuses are on the same playing field, only they're moving too. (shocker!) so what, in addition to moving, should an idiot do? I think an idiot also needs to fail. --- failure can take on many forms. it could be: - leaking an API key - spending $10k on a database query - breaking production these failures sit at varying points on the spectrum of fire-worthy offences. it's important to note that there's also only so much room for mistakes before they start having consequences. there are, of course, precautions you can take. ### know your risk profile it should go without saying that you know the risk profile of the actions that you take. this is hard to do when you don't know what you don't know. before making a change, here's a list of questions you can ask yourself: - is this change easily **reversible**, with minimal impact? - what's the **worst case scenario**? - **who** would care if things went wrong? reversible changes are ideal because if anything looks awry, you have a known state to revert back to, and can buy yourself time to rediscover blind spots you may have had. this is why development environments are helpful, because when you have a place where things are allowed to go wrong, you more quickly realise the difference between a real, potential failure and an un-calculated risk. ### know your audience engineers can learn a thing or two from customer-minded colleagues in marketing here. not everyone is going to want to know every step of what you are doing. selecting key points of information to deliver as well as how best to keep it digestible is a skill that cannot easily be narrowed down to a science. what works for one team may not work for the whole org. learn from past threads what people decided to be relevant, what people have pushed back on and what had been left ACK'd. no feedback could potentially be good feedback. ### know what you can't change there will inevitably be people who approach problems differently, and they'll have their own reasons for doing so - valid and/or known to you, or not. for this reason, it's important to consistently ask for feedback, or ask others what they would have done differently. these things are (usually) better out than in. not everyone approaches knowledge-sharing in the same way. some people are naturally proactive about explaining their decisions, while others are more inclined to share when asked. understanding these differences can help you identify opportunities to learn, even when mentorship isn't explicitly offered. you can also learn by observing the behaviours of high-performing peers, adopting what is clearly working in their favour. however, there's a difference between learning through observation and receiving active mentorship. individual excellence and the ability to develop others are two different skills. recognising that distinction can help you become more intentional about how you learn from others. to me, mentorship and stewardship are very closely connected. mentoring is a proactive, ongoing, and generous effort in uplifting others. it's about recognising that sharing knowledge and creating opportunities for others to grow are valuable contributions in their own right. this doesn't guarantee that a mentor will be available 24/7, or that they have an obligation to teach everyone everything. it's about being willing to share what you know when you can, and recognising that the growth of others doesn't always have to come with an immediate benefit to yourself. the offer of growth isn't always transactional. --- ### in conclusion your room (or swamp) for growth is limited when you're the smartest person in the room, but being the least knowledgeable person in the room isn't comfortable either. I think you should constantly be moving between different rooms, where you're sometimes the smart one, and sometimes the idiot.