As we have a few weeks left in the semester, I wanted to discuss the more creative apprenticeship patterns. This time I’m going to describe Craft Over Art, which is basically when a solution to a client’s problem can be solved with something that could work…or we could take it and go above and beyond. It’s being more innovative than just settling for a solution just to have something.
I found that the pattern is interesting because it emphasized the importance of how the things built for customers can still be beautiful but must always be useful. If it strays away from being useful, then it no longer counts as the craft.
I also found it to be thought-provoking because it brought up how people are truly in charge of how a problem gets solved. No one can force you to code something a certain way if they do not know a way to solve it on their own, which is why your role exists in the first place.
The pattern has caused me to change the way I think about my intended profession because your work can still reflect you in terms of creativity. As a person, I think I am more on the creative side and incorporating more ideas into creating something for people sounds pretty cool. If I had to follow a super rigorous structure, I may feel limited in what I can do to produce work that makes me happier.
The one thing I have to disagree with in the pattern is the part where it mentions that someone is suddenly no longer “part of the craft” if they deviate a little further. Who sets these boundaries? I do not want people to feel like they are not “enough” to be considered a real craftsman or whichever term it is referred it as just because they were being extra.
Overall, I appreciated the action section which encouraged people to reflect on what projects they worked on or situations they may have found themselves in where they chose creativity over usefulness. At the moments where I have personally done so, I had felt more proud of my work, because I knew it was uniquely mine.
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.
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?
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.
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.
When using architecture patterns, how will you know which one to choose? Peter Wayner, an independent author for TechBeacon takes five architectures that the majority of programs today use and broke them down into their strengths and weaknesses. Through this, it seems like he is hoping to guide users to selecting the most effective software architecture pattern for their needs.
If this article does not clear up enough information, Wayner also brings up a book, Software Architecture Patterns by Mark Richards, which focuses further on architectures commonly used to organize software systems.
The fives types discussed in the article are:
- Layered (n-tier) architecture
- Event-driven architecture
- Microkernel architecture
- Microservices architecture
- Space-based architecture
The one I found most interesting is space-based architecture because at first when I thought of space, I was thinking of the other kind. The one with the sun and the stars and the moon. But then I realized–what does that have anything to do with software architecture? Space-based architecture is listed as “best for high-volume data like click streams and user logs” and I think this one is pretty important, especially during times like Black Friday and Cyber Monday. I personally experienced the frustration of not being able to access a site (adidas) due to high volume and it really does not help a business.
Another architecture I found thought-provoking is micro-services architecture because of the way Wayner introduced the concept, “[s]oftware can be like a baby elephant: It is cute and fun when it’s little, but once it gets big, it is difficult to steer and resistant to change.” The author providing an example of this made me think about how a site with so many users and things happening at once actually just had many different separate services but they were put together as one. I was a little surprised to think of Netflix in that way after all the times I’ve used it but it makes much more sense now.
Overall, I found all of the information pretty useful and clear to understand as Wayner described what they were and then listed the caveats and what they were best for. I would recommend using this as a reference or quick review of common software architecture designs if someone needs it.