From recent conversations with friends and professionals I’ve had genuine one-on-one discussions with, a common concern people have is whether they will continue to actually enjoy what they do. Today I’m going to discuss the Sustainable Motivations apprenticeship pattern. This pattern pretty much goes over scenarios people may run into throughout their careers in technology. There will be great days where people may be amazed that they are getting paid to create things and there will be rough days where people may be doubting if it is the right profession for them at all.
The points brought up remind me of a recent article from the New York Times titled Wealthy, Successful, and Miserable. What happens when the new-ness of what started as an exciting role to join in a company wears off and you are left off with unsettled feelings? It is up to individuals to keep going until they find what they love again or shift what they are doing a little to stimulate something new.
I like how the pattern encourages people to come up with a list of things that motivate them. It then tells them to reflect on what those things means or if there is a noticeable pattern from the things they have chosen. Having a list like this around to remind people of what they are working for is a reassuring way to keep them going. It reminds me of a post on LinkedIn I saw where someone kept a sticky note on their monitor screen that just had a number like “-$237.25” because it was to remind them of how much they had in their bank account when they started their job.
The pattern has caused me to think about the way I intend to work as someone who constantly likes to change things up or is not afraid of change. I do not disagree with anything in the patterns as it tells us to keep pushing and persevering by thinking about The Long Road, which is another apprenticeship pattern.
Overall, I think people interested in this pattern should read the NYT article I linked as well because it gives insight on the difference it makes when people do something that makes their work feel more meaningful.
For my second sprint retrospective, there is something I would like to reflect on in terms of a change to my first sprint conclusion. It turns out my build environment was not completely set up properly so I had spent some time with assistance from my teammates on configuring that. I would like to note that I have a MacBook so that made things a little different to work our way around figuring out what to change or test out. A very helpful link was from a question someone asked on Stack Overflow. Through the process of not being able to install angular-cli on my mac, it led me to installing nvm, where there was another series of instructions to follow through Github.
It is very relieving whenever we get stuck on something and are able to find similar scenarios from people around the world who have run into the same roadblock and they share advice on how to work around it. Thanks to their input, I was able to resolve my terminal errors and/or warnings that resulted from trying to build something. It also helped me try and see if I could assist any of my other teammates who were running into errors as well even on Windows. I would definitely continue using the internet as a resource when I get stuck on mac-specific issues. The same thing happens when an installation that is only available in .exe files is required, I must find a mac-appropriate version.
However, if I were to proceed any differently; I would have double-or-triple-checked what is necessary to move forward. If someone else were to follow these steps; I would highly recommend checking out the links I provided above when I was unable to install angular-cli on my mac.
So far, we have been hit with some New England weather™ which shows how we were able to keep moving and working despite a roadblock that we could not control. It is very relieving to know we are now all on the same page and are working on moving forward together to contribute to the AMPATH system from now until the end of the semester. Who knew something could be more relieving than finally seeing the login screen after the ng command and going to the localhost url.
A big update is we got some more information on the AMPATH x WSU collab right around the end of this sprint so I am looking forward to exploring that with my team. It will allow us to analyze what has been given to us and decide where to move forward with the project.
Overall this past sprint included a lot more learning and collaborating with my team. I’m excited to begin watching the walk-through videos that Greg uploaded of the wire-frames. They look like they are broken down well and all of them are combined into a playlist so I would say we are going to be learning a lot more. Stay tuned for the Sprint 3 retrospective!
Recently, I have been seeing plenty of messages along the lines of “We learn from failure, not from success.” As someone who used to regularly watch all of Casey Neistat’s vlogs from the beginning days, it is something that has been ingrained in me to take risks and know that if I fail, then at least I did not give up and allowed myself to try.
When I saw the Breakable Toys apprenticeship pattern, I thought this would be the perfect opportunity to discuss trying things! This pattern is basically trying to explain to us that you need a safe space to learn something even if you work in an environment that may not allow for failure. It encourages us to seek our own way to sharpen our skills and take initiative, which would increase our confidence.
I found that this pattern is thought-provoking because where would you be if you did not take all the risks or new experiences beforehand to get to where you are today? I used to study biology and chemistry until I gave computer science a real chance. It was a little daunting at first to catch up but I made it (so far). If I did not take on leadership opportunities when given the chance, would I have the observation skills I have today when it comes to being involved on a team? Probably not!
If you do not allow yourself to try something out or practice something, I think you would feel a lot more pressure. It was reassuring to hear that someone like Steve Baker also experienced something like that, which makes it a lot more normalized.
As kids, we started learning how to interact with the world by playing with toys and developing our own sense of physics. Through that, we took risks like throwing things, sliding things down places, and etc., until we figured things like “oh, maybe I should not have accidentally thrown that ball too high and it went to the neighbors yard!” But at the same time, you’re a little proud that you’ve gotten better at throwing the ball harder.
That’s the same thing with developing yourself in your professional career. I will allow myself some time and space to learn something without that pressure and it may surprise me, once again, how far I may go.
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?
For my first sprint retrospective, I wanted to start off by introducing what kind of project my team is working on and what we are hoping to do with it before I move onto the description of what is happening.
The project I will be working on for the rest of the semester has to do with AMPATH (Academic Model Providing Access to Healthcare); if you have not yet heard of it, it is a healthcare partnership based in Kenya made up of different organizations. Part of my sprint was getting more familiar with who they are and what we could potentially do to help them. It looks like they are mostly trying to ease or log more operations technology-wise to help people.
Our main tasks for this sprint were of course getting to know my team (classroom-wise) and getting our set-up tasks sorted. It is my first time using Trello for something and as a visual learner or visual person in general, I found it very convenient being able to see our “Product Backlog | Sprint Backlog | In Progress | Done” lined up. We decided to start by organizing because of course that is usually how projects are best done and kept on track. Along with setup tasks, we began by cloning the project and then installed Karma and Protractor.
So far, I cannot say anything failed (and hope I will not have to report that anytime this semester for the sake of us progressing) but I hope we will have more concrete plans for what is coming up next for Sprint 2. I think it also has to do with me as a person being so used to always working moving forward or on with the “next thing” and it’s just different not having that yet. That way there will be things to continuously progress on and track more efficiently.
However, if I were to proceed any differently; I would have gone back and gotten a little more background knowledge because I feel like we tend to tell ourselves “I’ll just go back later and review” but of course that doesn’t always happen. It’s just a fact when you’re a highly involved student who works on the side; but when you plan or set some time for yourself you will be able to do what you need to.
If someone else were to follow these steps; I would recommend going in this order: Getting to know your teammates, making sure the team has a solid enough understanding of what project we will be contributing to this semester, beginning setup tasks, and then setting goals for when you should check certain things out.
Overall, I enjoyed this first Sprint as I did not feel too much pressure in terms of what needs to happen yet so we can ease into producing software that will help benefit AMPATH.
On this weekly individual apprenticeship pattern post, I’m going to discuss Concrete Skills. This pattern is pretty much explained with someone wanting to be a part of a good development team but they have not yet built up their development experience. My reaction to this pattern is that this would be a comforting one for students in college or upcoming graduates (and even entry-level developers) to feel a little less pressure on bridging the gap between starting fresh and being an experienced developer.
Concrete skills are interesting to me because you can have all the knowledge and information but being able to take what you know and apply it to something is different. The main takeaway I got from this pattern is to learn things that you will be able to apply even when you are still in the on-boarding phase. This has caused me to change the way I think about my intended profession because of course I want to get started and involved in projects right away. I like the feeling of being able to help people out when I have down time at my current opportunity just because I get to sharpen up a skill in one area instead of just sitting there.
A good question proposed in the pattern stood out to me, “If we hire you today, what can you do on Monday morning that will benefit us?” It’s interesting to imagine yourself in the role of a hiring manager; they have to hope to understand you well enough so that they can trust that you will be able to do your job and have an impact on the company. This thought makes me want to continue what I’ve been doing in terms of pursuing different learning experiences that will help me become a stronger developer not only knowledge-wise but skills-wise.
I do not disagree with something in the patterns as it gave me something new to think about and look forward to using in my future. I found it useful to hear their advice on considering looking at other CVs as references of what we would like to put on our potential list of skills.
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.