The blog I reviewed this week delves deeper on the topic of design smells and the classifications of some of them in different situations, some of which we had discussed in previous classes and some new ones that prove to be important to know in the long run. this article focus on design smells in the UI/UX side of programming and more specific to this side but still very much important.

The first discussed is “Documentation for Power users” which is the separate documentation used on portals to different sights when users click hyperlinks, or the different section on a Website or application. the issue comes from the formating and the flow of said website many look very cluttered and the flow of information is jumbled up. One specific example that is used for this smell is the Use of Microsoft Excel, the main focus being that it is a universally used application and thus has universal tools that the users disposal, the issue with such a great tool as without distinct tools being separated from the ones a user might not use in order to optimize the users experience it overwhelms them. this goes for all users as there is no case by case optimization, one solution brought up would be to dissect the application into separate products in order to better organize the UI for consumers in different situations, such as one made for educational use and one for corporate.

Another Smell that is discussed and closely relates to the previous is “Excessive Iconography”, this smell focuses on the use of unclear icons to display information in large loads, if we look at the example used in the blog of Xcode on Mac with many of the icons and labels out all on the same display to overwhelm the developer, making the tasks more difficult. the issue isn’t that the Labels or the Icons are not clear, but there are to many options and features present on the same screen. one way to combat this is to structure the application into smaller instances including all features that are connected together, allowing for clearer labeling and better overall experience for users. one personal example of this kind of structure I found was on Jira which structured its features according to what the user needed, allowing for a seemless UI and better experience. it did this but hiding features entirely that were not necessary and clearly labeling its tools.

Yodaiken, Aaron. “Ux Smells.” Medium, UX Collective, 7 Feb. 2017, https://medium.com/user-experience-design-1/ux-smells-fa971feef820.

From the blog cs@worcester – Marels Blog by mbeqo and used with permission of the author. All other rights reserved by the author.

This week’s Craftsmanship Pattern is another important one, breakable toys. This stands for the idea that experience is built upon failure just as much, if not more, than success. This idea is very good, as no one wants to fail, but failing is one of the best ways to learn, as if you are always successful, it is much more difficult to learn what does not work and what to avoid. The idea of never failing means you will never take any risks. To quote one of my favorite memes, “You didn’t grow. You didn’t improve. You took a shortcut and gained nothing. You experienced a hollow victory. Nothing was risked and nothing was gained.” While the above is pointed at cheating in a very difficult video game instead of “Gitting Gud” (intentional spelling) to pass a difficult task, I feel like the same idea applies here as well. It is important to learn what to do to succeed from what does not work, and what does work to continue using it.

To help with this growing, and similar to last weeks, it can be good to set up a private space where you can seek out this failure to learn from the experiences. For projects that you can fail on, try to build you own minor application, maybe a calendar or address book, for example. Things that are not too big, but still good enough to allow for failure without negatively impacting you. One highly recommended thing to do in the book is to create your own personal wiki, as you can use it to record what you learn. They are also nice since they can be simple, but still allows you to learn about things like HTTPS, REST, parsing, web design, etc. Sticking with this long enough will teach you about many things you many not have been exposed to otherwise, again creating an overall positive experience, because you will have some failure along the way, but how you overcame the failure is important. The book shows an email that Linus Torvalds saying that he is making a free OS based loosely off of minix, and those who know know where he went with this, and that is where we got Linux.

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.

This pattern is as clear as its tittle. Here’s the context given: you have realized that you’re not the first person to walk the path and that you are spending a lot of time exploring blind alleys. The problem is that you’re walking along a path with no idea of what’s around the next corner or how to prepare for it. You need help and guidance. The pattern doesn’t fail to recognize that our field is very young and therefore has few recognized masters. The solution is then to seek out those who have gone ahead of you and strive to learn from them.

I agree with the pattern because finding a mentor or someone that can supervise the work of an apprentice saves so much time and helps with building confidence. The pattern mentions how hard it is to find mentors sometimes and I can relate to that as I have found myself trying to find a mentor but it has always been hard. That being said, joining online forums, discord servers and being on “Tech” twitter has helped me make meaningful connections. I have come to understand that it is extremely important to find a community and put myself out there.

Another interesting fact they mentioned is that when trying to find mentors, an apprentice must remember that we’re all walking The Long Road and no one knows everything. It can be tempting to feel that your mentor must be a master because they know so much more than you do. That temptation must be resisted, because you do not want to become so disillusioned with your mentor’s inevitable weaknesses or blind spots that you feel you can no longer learn from someone who still has much to offer.

Something to remember is that your apprenticeship is unlikely to happen in isolation, and just as there will be people ahead of you, there will also be apprentices who have not yet reached your skill level. The other side of your search for mentors is that you must be willing to provide mentoring to those who seek it from you. Passing along what you have learned from your mentors is one of the ways in which you can begin the transition to journeyman status.

From the blog CS@Worcester – Delice's blog by Delice Ndaie and used with permission of the author. All other rights reserved by the author.

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

The ‘dig deeper’ apprenticeship pattern imagines a scenario where you have familiarized yourself with a number of tools but only enough to be able to implement them into your own system. You do not take the time to properly engage with these tools, and you only ever learn enough about a tool to get through your own individual work. This superficial understanding of your tools can lead to issues, and you may have trouble recognizing and solving bugs that arises because of a given tool. The solution is to take the time to acquire a more in-depth understanding of these tools and technologies. This will give you a good foundation to build off as you learn other tools and will give you a more holistic understanding of the systems you work on. You should learn enough about the tools you used to be able to solve any issues, but you should not completely devote yourself to becoming a specialist in those tools.

I think this apprenticeship pattern is interesting. I am interested specifically in the Hoover and Oshineye recommendation to become familiar with debuggers that show you your running program, become familiar with wire-level debuggers, and be willing to read specifications. I knew that different types of debuggers exist, but I was never sure in what situations you would use them. I should follow this advice and do some in-depth research on at least the debuggers they mention. I also thought it was interesting that they recommend reading through specifications for tools; I do try to do this whenever I am introduced to a new tool.

I am definitely guilty of only learning a tool enough to use it in my own project, but I want to get better about understanding the tools I use. I think the advice in this apprenticeship pattern is very useful in this way, particularly the advice to obtain information about your tools from primary sources. I think being able to read through, parse, and fully understand specifications and defining theses would be beneficial to my career. I would feel a lot more confident working on a system with tools that I can comprehend the workings of. I think this is a good way to develop my skills and prepare for my future career.

From the blog CS@Worcester – Ciampa's Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.

This apprenticeship pattern is all about expanding your knowledge about the tools you use and that if you find yourself in a situation where you are facing problems on the applications and different utilities that you have picked up over time has started to become a burden. This can be due to you using an unreliable source when learning about this product or just not going deep enough into the tool and only using what you needed at the time. This then can lead to troubles when you are put to the test or see a problem you have never faced before. The solution to this problem requires you to go beyond and start looking at the different nuances and inner workings of the programs you are working with.

Here this problem can be seen when you are perhaps interviewed and they ask you about projects that you have worked on. They then ask you about what you did and you can say that, but you don’t know exactly how it works all together, you coded some part of the backend but can’t exactly explain how that section functions. The background knowledge of the project is lacking in areas that could be problematic when you need to work in relation to that knowledge This is a problem and that you should instead take the initiative in understanding more about what you are working with to boost yourself and be prepared for a situation when this knowledge is required.

I myself could devote much more time into learning more about the tools I use and more about the projects I am working on. I could perhaps put some time into learning more on what is going on with the LibreFoodPantry and how the other groups are working to get a better idea of the situation. The job listings and internships out there are expecting more than just basic knowledge of the tools they list and use. There is much more with docker that I could be doing and figuring out issues that pop up from time to time if they are even fixable or not.

From the blog CS@Worcester – kbcoding by kennybui986 and used with permission of the author. All other rights reserved by the author.

The sweeping the floor pattern is all about earning your dues. It’s a rite of passage for any apprentice to earn their place in their respective workshops. Over the years I’ve gotten my haircut countless times. In a barbershop, you’ll likely come across a younger individual who all the barbers are always cracking jokes on. This individual also has a very important role to play within the shop. Although the shop’s main attraction is the barbers, the individual or individuals who sweep the floor are the unsung heroes. They allow the barbers to continue doing their work without having to spend the necessary time to clean up after themselves. The work the sweepers do come with a couple of benefits. Allowing them to earn some cash, as well as giving them an opportunity for them to learn how to become a barber. With all the time they spend in the shop, they get to watch closely from the sidelines as the barbers portray their skills. This relationship can also be seen in apprentices who wish to become software developers.

The authors make mention of things you can do in terms of earning your keep at your internship. Picking up the grueling time-consuming tasks that seasoned members of your team don’t like to do or don’t have the time to do is not only a great way to learn something new, but it also helps your team out. Although your contributions may take significantly less skill, your contribution is still valuable. The message here is to make the most out of each opportunity that you’re given.

While I agree that these sorts of things should be taken up during an internship or apprenticeship, I do not believe that taking up these sorts of tasks as an employee is a suitable thing to do. There may be times where picking up less technical work may be necessary, but always taking up these types of tasks on your team could allow your teammates to feel comfortable with giving you bottom of the barrel work regularly, which could speak for how competent your teammates think you really are.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

Christian Shadis

In the apprenticeship pattern Use the Source, Hoover and Oshineye explore the importance of learning from reading code from open-source projects. They start by explaining how young programmers often struggle to self-assess their code, since many have not seen enough professional-grade code to understand how theirs stacks up. Luckily, all the open-source code you could ever want is freely available to any developer. Hoover and Oshineye encourage the reader to use these resources as much as possible to gain a better understanding of code inside its context in a working software system.

This pattern closely resembles the advice I recently received from a software engineer family friend. She was transitioning from test automation to full-stack Python development and offered some insight into her job search process and some strategies to use for myself. Her main piece of advice was to browse GitHub for code written by other engineers – open-source projects, employees from the company at which you are applying, or anything else which could prove useful.

I started my Computer Science journey later in my academic career than I would have liked to, having switched into my school’s CS program toward the end of my freshman year in college not knowing anything about the discipline. I am still learning what good and bad code looks like, and how to take the concepts from classes and implement them to scale in deployed software systems. My time in a traditional classroom setting is quickly coming to an end, and I must transition my focus to self-education

I hope to use this pattern throughout my career, but especially so in the first few years. Since I started my CS journey, Git has been a good friend of mine, and I have always been interested in getting to know how it works so well. As such, it would be fitting to start by looking at the code for Git, focusing on the use of data structures. I still feel as though my biggest weakness as a developer is understanding how small microservices and programs interact in a much larger environment. Looking at the source code for distributed systems will give me valuable insight into how the puzzle pieces fit together.

Reference:

Hoover, D. H., & Oshineye, A. (2010). Perpetual Learning. In Apprenticeship patterns: Guidance for the aspiring software craftsman. O’Reilly.

From the blog CS@Worcester – Christian Shadis' Blog by ctshadis and used with permission of the author. All other rights reserved by the author.

This apprenticeship pattern talks about how software developers should jump into the deep end. Many developers take small, safe steps in their career, and this sometimes leaves them unsatisfied. This dissatisfaction could leave developers feeling like they are in a rut, and not just a plateau. When someone is on a plateau, they are consolidating their skills through hard practice in order to reach the next level. However, when a software developer is in a rut, their bland competence eventually decays into mediocrity. To avoid being in a rut or staying in one, a software developer needs to grow their skills, confidence, and portfolio. They need to take on more responsibility, do bigger projects, tackle more challenging tasks, work in larger teams, or try new places.

This apprenticeship pattern discusses how developers should do just that, they should jump right into the deep end. What software developers should not do is sit around and wait until they are ready, that’s a recipe for not doing anything. Instead, when software developers are faced with a challenging role or position, they should grasp it with both hands. This is because growth only happens by doing things that push you out of your comfort zone. If you only do what you are comfortable with, then you are not pushing yourself hard enough.

Of course, doing something like this comes with great risk. If bite off more than you could chew, then things could backfire. This apprenticeship pattern specifically mentions that jumping into the deep end does not mean lying about your qualifications to take a job that you can’t do or doing tasks without adequate preparation. Instead, it means taking on the promotions or the foreign assignments that you were offered. The key is that when taking on a new opportunity, you should assess the risk and difficulty to make sure that your head is above water.

Personally, I think this pattern is something that all apprentices are going to need. Everybody in our craft needs growth to stay on top, and growth doesn’t come without trying new and challenging things. It’s important to take that leap forward if you feel like you’re in a rut. However, when considering new opportunities, it is vital to evaluate the risk. If you find yourself with your head underwater then that means you took on too much risk and you’re drowning. To offset some of the risks, it would be wise to find mentors and kindred spirits who would give you advice and help when needed. It would also be wise to create feedback loops.

From the blog CS@Worcester – Fadi Akram by Fadi Akram and used with permission of the author. All other rights reserved by the author.