Having a software-induced identity crisis? Worry no further, I guess that may be a more common thing than I would have expected! This week’s individual apprenticeship pattern will be Use Your Title.
I thought this was really interesting because there is such a high likelihood that there will come a time when you find yourself in-between positions but called something higher because there was no pre-existing label or category that would perfectly suit you. It may feel weird to have to explain yourself in your title to someone who assumes what you do based on what they see or hear. But perhaps, I wanted to add that I feel like someone could just be feeling imposter syndrome; which is something I heard is common for women in certain career fields tend to feel. What if someone does 100% fit the title they feel that they need to explain their title for but just does not see themselves the way their supervisors do.
I like how this pattern tells us that the title is due to the organization we work for, not necessarily us whether or not it does not match us enough or over-exceeds our abilities. By removing ourself from the current situation, I like how we are encouraged to think how we would view or think about someone’s role based on what they actually did in their job. This perspective was thought-provoking to me because I had not considered
Something I tend to think about is knowing when you need to step out of your comfort zone. When should you move on from one thing to the next; how do you know to take that risk? Seeing the little feature on David Hoover’s actions after he achieved his goals, it was interesting learning how he decided to move forward by continuing to draw his own map.
Overall, the pattern has caused me to think a little more on my intended profession in terms of where I want to end up. Right now, assuming I will have a junior/associate position after I graduate and later become a ‘senior’ or ‘lead’; where would I like to go after that? What will be my ongoing goal?
Apparently doctors hate their computers, according to an article titled Why Doctors Hate Their Computers by Atul Gawande. Gawande started out the article by mentioning Epic, a company a lot of people know of because it is a leading provider of software for the healthcare industry. It’s funny because just the other day, a classmate who will not be named groaned when he heard Epic being mentioned by someone, as he works in a healthcare center.
I found the reading was interesting because I have no intentions of becoming a medical doctor one day but was able to hear about how it is being one while interacting with technology that exists today.
It seems like the tension of logging everything caused the system to make doctors’ lives harder instead of easier; this was noticeable when Sadoughi was talking about how she had to look over all notes from different doctors including herself per patient. Instead of being able to just see what is going on right away; it would take up time to gather all information and even then it was not always helpful because some notes were different than others and became dated. And then work-life balance had to be thrown off a little because people had to spend extra time, up to hours after-hours to catch up with the system and review things from the day.
The real customer for the system seemed to be patients because they have some benefits from using the system like logging when to take medications or see how they are doing. Doctors are also able to monitor how they are doing and communicate with them by being pinged.
The lessons from this system do not only apply to Electronic Medical Record systems; they also apply to working in life because burnout can happen to anyone in the workforce. I thought it was interesting how one of the ways doctors were trying to save time and prevent burnout from technology was by hiring in-hospital scribes or even virtual scribes when necessary.
The reading has caused me to changing the way I think I will work based on if I ever end up creating software that affects people’s healthcare by considering how much time it takes to interact with it, no matter how “cool” or “innovative” it may be. In terms of the topic itself, the reading has caused me to think more about software that has altered people’s professions as a whole; which I thought of before but never this deeply.
I do not disagree with anything in the reading for now as I do not personally know what it is like to work in a profession that is not traditionally non-technical and then gets transformed into something that relies on it.
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.
Hey guys, here’s to another (and my last) semester of this CS series of blog posts!
Hopefully you will HIIT–or should I say reach–all of your professional and personal goals for this year. There’s so many things to always keep improving on but it’s always easier when you break things down to smaller changes or achievements.
Here’s a picture of one of my personal goals as can be seen in my university’s Wellness Center:
One day I will be able to get up there without being lifted…alright I’ve gotta get back to practicing my jumps.
As my last fall semester comes to a close, I wanted to write about an article on something pretty interesting I learned about in my software construction and design course.
On Stackify, Thorben Janssen wrote Design Patterns Explained–Adapter Pattern (with code examples). Overall, this article re-instilled how design patterns make it easier to write more well-structured and maintainable code.
I found it useful to see how Janssen discussed the two different versions of the class adapter; the class adapter pattern (which implements the adapter using inheritance) and the object adapter pattern (which uses composition to reference an instance of the wrapped class within it).
Similar to how we learned the concept in class, something I appreciated is the “real-life” example or comparison used to describe the physical adapters we use when traveling. When we are traveling and do not have compatible power sockets, we must find a way to be able to charge our use our devices without having to change the whole make of it. A way of doing so is by using adapters; which does not change the overall product or device, it just allows you to be able to plug it in.
An situational example that I can think of when explaining adapters is if you have ever been zip-lining or done a ropes course (like Go Ape) where you are attached to a harness. When you are transferring from one line to another, you can use a metal contraption which helps guide you while connecting and disconnecting from paths. That metal contraption serves as an adapter, not changing what you are but allowing you to use something.
I agree with what message Janssen is trying to express about how great design patterns are (the adapter pattern specifically) when it comes to writing code. His content allowed me to think about real life situations in code form when he introduced the basic and premium coffee machines to brew coffee using the adapter pattern. One of the best ways of learning concepts, in my opinion, is to compare it to a real-life situation and then show people visualizations to help them better understand what you are trying to explain and the article did both.
Testing, testing. I may need your approval on this article I read by Software Testing Magazine on Approval Testing. Approval testing, as defined by this article, is a way of software testing that results in presenting the before and after of an application for a user (ex: software development team) to review it and potentially approve it. It’s more of a visual representation of testing and one of the major cons is how the results have to be checked manually.
Some testing tools mentioned include: Approval Tests, TextTest, Jest, Recheck, Automated Screenshot Diff, Depicted (dpxdt), and etc.
The main purpose of the software testing tool, using TextTest for example, is checking that the text output after running program from the command line in different ways.
What I found interesting is how a user can see that a test technically could have “passed” or “failed” but still decide to mark it as the other because they choose what feature they are looking for in the end. This makes it a little more flexible to use approval testing as it is more of a guide or guideline for a user instead of only seeing one word and then a short description of what could have gone wrong. I think this process is much more transparent or descriptive with a user about what could have gone wrong or what went right.
One way the content has changed how I will think about the testing is how there are so many more types of software or programs out there than we can imagine which help us better code or create our own software and programs. This one is especially good for visual coders and testers who like to see their results firsthand to compare what they are expecting with what they actually got.
Overall, I found this article was useful because it introduced me to thinking about a better way of logging the differences between what the reference result is versus the actual result. I did not disagree with any of it since it showed us how we can use approval testing to our advantage while still being honest about its limitations.