softwareyoga.: How to be invaluable employee?

How to be invaluable employee?

Or in other words how to bring more value to the company as a result of your work?

You got to show them how your work is making a difference to their world – A world where $, savings and time to market has precedence over exceptions, design patterns and interfaces.

Listed below are some aspects that will definitely get you recognized as a programmer who goes the extra mile beyond and above the official duties.

1. Understand what the end users want in the software. Talk to them. Figure out the things they don’t like in the existing system, things they would like to improve etc. You have to solve their problems using your technical skills.
2. Identify what modules or components have the most defects in your system. Come up with high level technical approach to solve the issues. Present the ideas to the management, explain what benefits it would bring to the company and how it can save time and cost. Use statistical figures to explain how your ideas will bring vast improvements.
3. Identify things that are being done manually or with complex workarounds. Eliminate them or handle them in a better way.
4. Speak to management on what they think are the biggest problem areas. A lot of the times, getting input from someone who is away from the technical stuff helps immensely.
5. Evaluate new technologies for your product and present to the team and management on what benefits they may bring.
6. Identify and improve workplace processes. You will surely have few issues regarding the way some things are done in the company. Figure a way to alleviate the issues.
7. Many a times, the project managers might over-promise or set extremely tight deadlines – not because they like sucking the last drop of blood out of you, but often because they don’t understand enough technically. Have a discussion with them on their expectations. With your technical knowledge, provide them inputs on whats possible realistically and how the scope can be altered so that everyone is a winner.
8. Draw comparisons of your work with other industries and bring in the best practices. Often, you can draw inspiration from the most unexpected places.
9. Mentor junior employees. Train other employees on various topics and practices. In most companies, you will have someone in the company who you aspire to be like some day. Meet them and ask them if they could be your mentor or if you could shadow them in their work.
10. Automate stuff outside of your product – Find people within your company who are not as tech savvy as you are. There will be some one out there who needs a helping hand. Solve people’s problems.

In conclusion, I believe that a programmer should get involved in other activities in a company, not just coding. It serves two purposes – provide you insights from a non-technical viewpoint and an understanding that programming is not the center of the universe.

Career Development links

Five Signs You Should Be a Low-Code Developer

If some or most of these traits resonate with your approach to work, then you’ve got what it takes to be a low-code developer. In this role, you’d understand that software development is about reaching the business goal and helping end users. You’d want to talk to users, understand their requirements and work closely with them in short, iterative cycles. Most of all, you’d advocate for the business value of IT and find great job satisfaction from making your customers and end users happy.

techcrunch: On Secretly Terrible Engineers

That is the transformation we need in engineering. We need to start with the assumption that engineers are smart learners eager to know more about their craft. No, an individual may not know the specific framework you use for front-end development, but then again, there are so many that it is hard to know all of them. Engage them! Mentor them! Buy them a god damn book! 

We need to move beyond the algorithm bravado to engage more fundamentally with the craft. If people are wired for engineering logic and have programmed in some capacity in the past, they almost certainly can get up to speed in any other part of the field. Let them learn, or even better, help them learn.
I am not unbiased here, having gone through this process myself. I started programming in second grade. I wrote tens of thousands of lines of code in high school, programming games and my own web server. I got a Mathematical and Computational Science degree from Stanford and continued coding. I should have been a software developer, but after a series of interviews, I realized the field was never for me. So much hostility, so little love. 

No one ever offered me a book. No one even offered advice, or suggestions on what was interesting in the field or what was not. No one ever said, “Here is how we are going to bring your skills to the next level and ensure you will be quickly productive on our team.” The only answer I ever got was, “We expect every employee to be ready on day one.” What a scary proposition! Even McDonalds doesn’t expect its burger flippers to be ready from day one. 

That’s not typical in our economy, and as computer science expands in popularity, we need to ensure that the next generation of talent feels welcomed. There are far less secretly terrible engineers than we might expect if we give them mentorship and support to do great work. There is a whole group of secretly great engineers ready to be developed, if only we realized our field’s animosity.

Funny and true.
If Carpenters Were Hired Like Programmers


Facebook Coding Interview tips:
https://www.facebook.com/Engineering/videos/10153034561822200/