The latest articles on DEV Community by Arthur Flam (@arthurflam). https://dev.to/arthurflam https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F150469%2F3a13c797-013e-4738-92b3-5f38bea62217.jpeg https://dev.to/arthurflam en Arthur Flam Fri, 29 Mar 2019 13:06:32 +0000 https://dev.to/arthurflam/advocating-internally-for-new-technologies-4ac6 https://dev.to/arthurflam/advocating-internally-for-new-technologies-4ac6 <p><strong>Changing the status quo</strong> and adopting new technologies is never easy. Whether we are talking about a new database, library or even way of approaching your problems, you should know what your are in for.</p> <blockquote> <p>Of course, your difficulties will be very different depending on the size and culture of your team! </p> </blockquote> <p>Do you even want to get started ?</p> <ul> <li> <strong>What are the Benefits ?</strong> Whether it is ease of development, transparency, adaptability, performance... A case has to be made. <ul> <li> <strong>Knowledge :</strong> you should know the manual/tutorials inside and out. For bleeding edge projects, you should have read some of the source.</li> <li> <strong>Experience:</strong> before you make everyone adopt something, you really should have toyed with it and it should have proved itself in a non-critical project. Ask around what people think.</li> <li> <strong>Trust/Authority and commitment</strong>: can you push this through? </li> </ul> </li> </ul> <p>What will make the project successful?</p> <ul> <li> <a href="https://en.wikipedia.org/wiki/Rough_consensus">Running code and rough consensus</a>: <strong>do</strong> things, write code, take responsibility, and steer discussions away from uninformed opinions and towards what brings the most value.</li> <li>Don't break things <em>without reason</em>. Provide guidance and automation to update/migrate downstream clients/users. <strong>Backward compatibility</strong> is boring but everybody will thank you for it. </li> <li> <strong>Onboarding:</strong> give assistance setting things up. Give advice about best practices. Offer solutions, do the work.</li> <li> <strong>Support:</strong> if you've built a consensus and brought people on board, don't waste everything. Proactively check-in with your colleagues, ask how things are going. Treat your your coworkers as <strong>clients</strong>.</li> </ul> <p>At some point you will need to evaluate your project:</p> <ul> <li> <strong>Be unbiased</strong>: consider all options, give fair assessments, be transparent, and always keep in mind what is most important to your team or users.</li> <li> <strong>Feedback</strong>: is huge. Only if you listen can you improve your work, or cut your losses early.</li> </ul> <p>Personally, in every <strong>new project</strong> I try to do two things like I've never done before. Never more, rarely less than two. It's great for learning, and soon you learn to judge things better. Changing <strong>existing projects</strong> and workflows is much more challenging: be gentle 😌.</p> <blockquote> <p>Did you like this post? Read more at <a href="https://talk.shapescience.xyz">https://talk.shapescience.xyz</a> :)</p> </blockquote> career beginners programming discuss