In reading the above article, it's pretty obvious that there are a lot of technical proficiencies that you need to have as a programmer. However, what stood out to me most were some of the intagible, fringe behaviors that you wouldn't initially think would make a good programmer. First and foremost, I think taking responsibility of your mistakes stood out to me because, even outside of coding, it's an honorable characteristic to have, but incredibly hard to develop. No one wants to raise their hand when they're put on the spot and an issue surfaces. However, if you're able to do this, you will not only develop trust with your team, but respect, which is beyond important. Speaking of your team, I liked the point about pair programming with people that have more experience than you do. While it can be nerve wracking to admit you don't know how to do something (which is often difficult for me personally), it is exciting to see how someone else executes a particular task. A lot like watching someone paint, you learn the 'method to their madness,' which can only help you grow in the long run.
At one of my past jobs, we had monthly meetings to go over 'sales goals and achievements.' While these meetings were helpful to the sales team, they were largely unimportant for my position and ate up over half of our work time before the morning deadline. The behavior of 'Skip a Lot of Meetings' was amazing to see. Where I worked, this would have been severely frowned upon, but the line "Your company pays you to write code. Not to talk about writing code," was like music to my ears. The fact that this mentality even exists makes me incredibly excited for the direction I'm about to take with Turing. Lastly, and, arguably, most importantly, was the idea of acting as a leader, not a boss. I've experienced some difficulty with this when I started running my small business, but quickly learned that it was best to lead by example. If someone needed to do something, it was easier to show them how to do it than to tell them how to do it. This not only saved me a headache in the long run, but helped the other person learn something new and, ultimately, work more efficiently and effectively. In turn, I increased my own personal experience and developed a closer relationship with my peer.
Checklists are something that I have always been an advocate for, though I haven't always been at the forefront of following them. Often times I'll make one, follow it for a time, only to let it fall by the wayside and attempt to 'wing-it.' Sometimes this is successful, but more often than not a task or two end up being left behind. Checklists, in my mind, serve two purposes: to organize your thoughts on what needs to be done and to double check that nothing has been missed. As a student at Turing, this could be something as simple as knowing that you need a an html tag before a body tag or keeping track of which assignment needs to be completed first in order of priority or urgency. As a professional, the small things are equally important to keep track of (much like in the referrenced article), but your checklist needs to accomodate a growing list of responsibilities, such as permissions you may require from other departments, client needs, deadlines, etc. Starting the habit of a checklist can be difficult, but it will be much easier to accomplish at the onset of one's coding experience as opposed to realizing you need it several years into a career.
How to Hire Like Google & Facebook, Four Essentials of Strenghts-Based Leadership, and Debunking Strenghts Myth 1: Adopting a Strenghts-based Approach Doesn't Mean You Can Ignore Your Weaknesses Reflection
Personally, I love the idea of strenghts-based development and I think it is something that more companies, particularly larger ones, should adopt. Too often companies focus on 'areas of improvement' where things can be made 'better,' versus taking what they already have and figuring out how to utilize it best. My only questions about this type of development are how successful it truly is and whether or not there's a limit to it's implication? About a year ago I read an article about how a new CEO of Zappos was implementing a different style of business structure where there were no bosses, no corporate heirarchy, and employees were encouraged to focus on their passions. A few months later, it seemed that the results were divisive, with employess noting a lack of structure and confusion about what their actual job was within the company. This may be a stretch for the topic at hand, but Zappos' approach seems like an extreme side of strenghts-based development.
When considering my top stengths, the first things that come to mind are my problem solving abilities, leadership, and accountability. When it comes to solving a problem, I try to look at it from every possible angle. This could be via doing thorough research, consulting with people that have more expertise, or simply stepping back and looking at the issue objectively. Each provides a different insight, which not only allows me to increase my knowledge base, but hone my abilities to be more effective and efficient. Leadership is a quality that I often like to think I embody, but sometimes even having this thought seems like a contradiction. A leader, to me, isn't someone who touts their leadership abilities or 'takes the reins' when others are in peril. Rather, I think a leader should be someone who leads by example, provides help when able, and is patient and understanding when others are discouraged/frustrated/upset etc. The idea of a humble leader resonates with me because they imbue an aura of leadership, but consider their renown a privilege as opposed to a responsibility. In that same vein, I like to think that I have a sense of accountability. This can often be difficult when confronted with a problem where you may have been the root cause, but after purposefully honing this skill over the past few years, accepting my mistakes and shortcomings has allowed me to learn from my mistakes and form stronger relationships with my peers. Where shirking responsibility onto others or avoiding issues due to fear of confrontation can cause tension and unease, simply saying "My bad!" can promote growth and lead to a quicker resolution without 'beating around the bush.'
When considering my new career in software development, I hope to tap into my strengths by working my way up. While I have a profound knowledge about a lot of things, I am undoubtedly wadding into unfamiliar waters. There is a lot I don't know and approaching coding from a place of respectful ignorance will not suppress my strengths, but rather allow me to redevelope them in a new and exciting way. Once I have gained confidence in my knowledge of software development, my innate qualities will inherently adapt and shine through in everything that I do.