This particular behavior resonated with me because of some advice I got at a former job. I drove a truck picking up and delivering books for the library district. As I was training, I asked what happened if I forgot a box and the trainer told me, "don't worry about it, it will still be there tomorrow." He took what seemed like a major issue to me and made it simple. In relation to the article, I like taking the focus off of the superficial. This allows you to focus on the elements that are truly important to accomplishing your goals.
Coming from an English and creative writing backround, I actually enjoy the process of editing. Even when writing an email I have a tendency to read it several times to make sure everything is correct or see if there is a better way to say it. It seems that a similar approach can be applied to coding. There are lots of opportunities to clean up and solidify your code to make it more accurate and precise. I want to make sure to take advantage of shorthand options to have the cleanest, easy-to-read code possible.
This is one behavior I think I will have to work at. I have a tendency to try to get everything right on the first try. Sometimes by jumping in without all of the answers will lead you to learn a lot more. As the article says, code is cheap and often replaced quickly. I think I need to focus more on taking risks and looking at the value of learning lessons as I go.
As I was reading I realized I fell into the 20% that hated the idea of a checklist. Most of my life I've relied on my memory to do things. I don't make a list for the grocery store because I feel like remembering all the items keeps my mind sharp. I never wrote down assignments in college because I would tend to forget them once I wrote them down. But looking at a complex topic like coding, I can see the benefits. There is so much to remember, if you don't help simplify things for yourself, you're bound to miss things that will need to be fixed later. By turning the more mundane aspects into a checklist you can rely on, you free up more brain power to work toward the more difficult problems.
What is your impression of strengths-based development? What questions do you have about this kind of development?
My impression was that strenghs-based development makes a lot of sense. In my previous position this was a big source of frustration for me because I felt like it was not utilized. As a digital marketing specialist, I was being told how to create and manage a website by someone in finance who wasn't even comfortable using a computer. By letting me use my strengths and them using theirs, we could've made a better product and accomplished more. My main questions are about the methodology as to how these are determined. What are the points of analysis? How are things weighted? Is there room for gray areas?
I feel my top strengths are working in a team environment and problem solving. I feel confident that in a professional environment I can get along with just about anyone to get a job done. Additionally, I like the challenge of solving problems and coming up with solutions. At a former job they put a sheet of paper outside your office and colleagues came around and wrote adjectives to describe you. These were some that came up frequently in the eyes of others.
When you're working on something that is hard to understand, it's easy to get frustrated. I feel as though I am a patient person with others, but not always with myself. I need to work on being patient with myself and giving myself time to figure things out. Additionally, I hope to use the career skills I've already gained to pair them with a new skill of software development. I think this would allow me to have a different perspective from many, while still being open to learning from those different from mine.