For this next installment of the Apprenticeship Series, I wanted to discuss Expose Your Ignorance. This apprenticeship pattern involves being more direct with people to have the faster route on the road to journeyman instead of protecting one’s pride to find other ways to obtain the knowledge they are seeking. When someone exposes their ignorance, they will be able to learn more quickly instead of trying to appear like they are capable.
Based on what I have learned of this pattern so far, my reaction is that it was useful seeing examples of how this happens in real life for people. To me, this was something I thought of before without putting it into a framework of sorts. I found that this was interesting because of the way they explained it saying, “One of the most important traits that a craftsman can possess is the ability to learn, identifying an area of ignorance and working to reduce it.” It shows how ignorance does not necessarily mean they are at fault of something, it just means they are willing to work to move past it.
Taking this as a lesson to think about, the way I work will be pretty much the same. I once almost made a task over-complicated because I wanted to find my own way to work on it instead of just asking another developer for their opinion on whether I was doing something correctly. After deciding to ask for help thought, we figured out that there was a much more simple way of going about it instead of changing a whole system of developing a certain feature. Due to this, I have gained more confidence to ask people when I am uncertain about something because in the end it would save a lot more time and avoid confusion.
I did not disagree with anything brought up in the pattern so far because I believe people should be able to communicate when they are not confident about something or at least ask for clarification. After some thinking, I realized I’ve never expected anyone to know everything so why should I feel like other people should expect the same from me?
So you either want to or have already been an apprentice for software development huh? I just read the section on the apprenticeship pattern for The White Belt and it was a nice beginning to approach what we are doing. It reminds me of a quote: “In any given moment we have two options: to step forward into growth or back into safety.” This is us stepping out of our comfort zone as we approach real-life situations and try to help them by starting our journey into development.
A summary of the pattern would be after some time of developing skills, someone may feel that their growth has plateau-d, however there still remains confidence in their abilities to do something. I found that this was interesting because as someone approaching a career where I will be a life-long learner of technology and ways to develop it, I never considered getting stuck or feeling like I was not getting somewhere.
Based on what I have learned about the pattern, I think it will change the way I work based on their advice to set things we have previously learned aside in order to “unlearn what we have learned.” I like the idea of approaching something that is new to be able to fully appreciate it.
I could relate to the situation they describe about sacrificing productivity in order to improve our skills. From on-boarding as a junior developer, it was a different experience trying to do self-learning while getting assigned tasks to work on at the same time. It was interesting trying to find a good divide between learning something while trying to develop things compared to using internet references.
I agree with how they mentioned not basing everything you learn in other languages based on comparing it to a base language that you know. This made me realize how I have been doing this for a while; I sometimes forget that not everyone knows Java or a language that would seem “universal.” It would help take away the stress of thinking in a certain language’s syntax or process; allowing people to just code something that would work more efficiently and effectively.
Overall, I would say that this pattern is nice to hear about in the beginning so people can approach it in a way that allows them to learn things with a fresh start to programming. I also just liked how they called it The White Belt so people can level up.
After learning some life lessons through the pages I’ve skimmed from my copy of The 7 Habits of Highly Effective People by Stephen Covey; this article’s version for software developers in test caught my eye. What exactly are the seven highly effective habits of SDETs? Here are the seven habits that Angie Jones, a senior developer advocate at Applitools, wrote about: being intentional, enhancing development skills, enhancing testing skills, exploring new tools, automating throughout the product’s tech stack, collaborating, and automating beyond the tests.
If anyone is interested in becoming a SDET, they should follow Jones’ advice as she is very familiar with interviewing SDET candidates. Something thought-provoking about the first one is how automation projects are not always the best option. Before this article, I understood that not everything required automation but it was the end goal for more projects or companies overall. This is due to my experience; for some reason I believed that just because the company I was at wanted automation for something that everyone else would too. After reading this, I am now understanding that automation is only the goal when it is aligned with the overall outcome.
I am noticing a consistent pattern of guides to becoming a good software developer or tester containing similar tips like “enhancing development skills” and “enhancing testing skills” as people in this industry must always keep learning to stay on top of what’s new. Due to the repetition, I have been trying to keep an eye out for the more unique ideas. One of the ideas that stood out to me more is the one of collaborating.
Jones listed careers ranging from business analytics to software development and mentioned how they would be good matches for pairing up with SDETs to help each other better understand certain features and the importance of what they will be working on. From a sociological standpoint, I like this approach to finding all the resources to complete a project outside of the department. As someone who is always looking for ways to connect with people or connect people to other people, this is an effective idea for helping companies and their people feel more at ease with their jobs. The SDETs may feel less pressure knowing they are not entirely on their own and can request help when necessary.
According to music artists, two is better than one. When it comes to designing code that has two parts, this may not be the case. In Max Kanat-Alexander’s article, he explains how he has a personal rule of needing to know how generic his code needs to be. He describes it as if he were designing an audio decoder and started out with supporting WAV files and then later needed to add support for MP3 files. His solution was for what he only needed on its own instead of having to copy and paste the common parts for the format; he emphasizes that “it’s not just two implementations that are bad, but also two locations.” Another rule Kanat-Alexander has for helping this stay consistent is to create code well enough to ensure you would ideally never have to go back and change it if another part of the code has to be modified.
I found this information useful because I believe that developers are always striving to be the most efficient coders they can be. In order to do so, using two of Kanat-Alexander’s methods would help them plan to code more effectively. Just imagine the potential headache of realizing you have to go further back to code you thought was finished and then even further back when you notice a change on top of what you originally needed to make. This will probably affect how I will work in the future as it will make me sit back and think beyond the task at hand. It would allow me to save room for potential add-ons without them crisscrossing, which would allow me to skip out on having to do more rework.
At the end of the article, Kanat-Alexander notes that the reader does not have to take this as a “hard and fast law of the universe” and I appreciate how he tries to help the reader but does not try to push them to do it his way. In terms of the subject, I do not think my thoughts have changed too much as I do want to learn how to code better and I would like to continue finding out about people’s coding structure process.