This method talks about how indulging in your own artistic nature isn’t always the best option even if you think the product would turn out better if you did it this way. If you are being paid to build something that will solve a problem, this method of Craft over Art explains you need to really consider the situation at hand. In this method, the situation that is discussed is that you believe that you are able to do something outstanding and fantastic that will impress your colleagues. In this situation, you are building something for a user. You shouldn’t be indulging in artistic expression. A lot of the times when we are handed with a task, we can sometimes think about the most outstanding ways to do something, rather than just to get the task done. This can go two ways. Doing something outstanding for a task can be great and have it’s benefits, but what will it cost the effectiveness of it? On the other hand, we can do the task at hand and that will be that. We won’t be able to put any personal expression in it, but is that a bad thing? Of course it isn’t a bad thing. This method seems to be very similar to function over form.
It is a matter of situational awareness. This is something I really enjoyed from this article. Make more straightforward choices and do not try to “sugar coat” solutions. As soon as you start making unfavorable trade offs in certain scenarios, the outcome will not always be as you like. in other words if you want a straightforward answer, you should provide a straight forward solution. Even though this isn’t always the case, I learned that you should always try your best to just try and perform the basic tasks first without adding anything extra or unique. Quality takes time, but having the correct operations in a product is what can make all the difference.
For sprint two our group was in waiting state. We didn’t quite have any tasks to work on at the moment and we were conflicted on where to focus our future workloads. We know we want to work on the server but also are coming up with a backup plan in case that does not work out. Our group worked a lot towards researching certain aspects about how servers work and talked about what incorporation we might need from other groups.
During our research, we found two tools that we plan to use for testing. These tools are useful in that Karma is more of a simple junit tester while protractor is end to end testing. As we continue to research more tools, we also want to familiarize ourselves more with the angular material. Angular is more familiar to us which is why it would be a good idea to work on the bottom navigation bar, however some of us enjoy a nice challenge too, which is why we would want to work on the server.
Hopefully by our next sprint we should have more solid understanding of what we want to do. We are most likely going to be working on the server but no one in our group has worked on one before.
This method talks about how there are tools that we need to master but we may not always understand how to master them. A lot of the times we try to be a master of all, when in reality that doesn’t necessarily work all of the time. What I mean by this is that when we are faced with a task, sometimes we think we understand each little aspect of the specifications. However, upon actually tackling that task, we aren’t really sure where to go. Like one of my previous entries on “Exposing Your Ignorance”, confronting your ignorance really focuses on selecting on skill, tool, or technique and really honing in to fill gaps in your knowledge about it. One of the points in this method that really caught my attention was it’s mention of humble, ignorant, and dependent team building. If you are working with a team of developers and each team member has this ideology that everything is “just because of the way it is”. this can lead to a multitude of problems.
One of these problems is bad team building. When you assemble a team of people for some sort of project, you want to be able to work together to share ideas. If a problem arises you all want to be able to come together and understand what the issue is so you can solve it as a team. If you all think that things are just the way they are because they are, this can often lead to disagreements among team members. Some team members might even think you are against them just because you disagree with them on something. It’s this idea of confronting your ignorance that is vitally important to understand. You should learn one thing at a time, that way when a problem arrives, you can put aside what you know, and focus on what you don’t know. Failure in a public place can be embarrassing, but it is exactly these failures that make it better. If you failed at something, you wouldn’t want to be ridiculed for it. Instead, you should learn from it and always be willing to learn more and more about the issue.
There are going to be many situations in which we will not be able to figure out a solution to something. Deciding what to do in these situations is a big portion of solving the problem. Sometimes we can get very frustrated and give up. Other times we will try mundane fixes that won’t even solve our main issue. One thing that we need to realize, however, is that we are not alone. Most often than not, some issues that we run into have been solved by someone else. There is no reason to tread dead water if a solution is out there. Finding the way to this solution is a key part in problem solving. So, what do we do from here? We seek out help.
The thing I liked the most about this method is that by seeking help, it shows our willingness to understand and continue to learn. It also teaches us how to figure something out on our own, even if we don’t know what that issue is. One main part I agree with about this method is that it explains how, since this field of study is fairly new, it can be difficult to narrow down the “masters of the craft” because an apprenticeship can only mean so much. The difficult part is finding that one person who CAN teach you and guide to on the right path. One of the hardest part about mastering something is finding a that specific master or network of masters in order to reach the goals you have set for yourself. You can’t expect to learn everything on your own, this is an issue in itself. You need to seek help, evaluate that help, and then decide if it is worth your time to continue to learn by them. If not, that’s something you will have to decide. One great modern tool that we can use to do this is the internet. A simple google search can solve a lot of our problems, especially in this field of study. But sometimes we also should be careful at which sources we are pulling from.
I learned a lot from this first sprint. A lot of issues were being run into and as a team we were able to overcome these obstacles to all continue. Something that I learned that collaboration can often lead to success because you may learn something about a topic that you may not know. Next I will explain some of the tasks our group has completed. First, we had to make sure all of us had a sprint backlog. These included tasks for our sprint timeframe that we should be able to complete. We setup a group environment on GitHub to clone our ng2-amrs repositories so we could get oiur AMPATH portal up and running. This is where we, and many others, ran into most of our problems. A lot of us had many different errors so it was very confusing trying to find fixes for all of us at first. We coordinated with other groups via slack channels in order to first find out who was having what errors. After posting about the errors and discussing them in the slack channels and amongst each other at our meetings, we started to research for solutions.
The fix fix for this was to run two commands in the node modules folder that fixed the package.json file. After this, we ran “npm run build-prod” and then this fixed the issue.
Often times we feel as if we may know how to do something, when in reality we may not know. Some problems that arise can may seem familiar but often times need more digging to figure out the answer or solution to. The Expose your ignorance pattern explains this by growing yourself in order to find a solution. The pattern states that we are not going to know every little detail about every software or domain we need to use in our jobs. There are people depending on us to perform a task, but the issue is what exactly do we do when we can’t overcome these obstacles? Even if you don’t know what you are doing or aren’t aware of a certain situation, it is always better to atleast look like or be willing to be competent in whatever the task at hand is. One great point that I think this pattern brought up was conceding your pressure and just telling your clients or colleagues that everything is okay, even when it is not. If you just tell people that thing are okay even though they aren’t this can lead to a massive snowball effect.
For example, maybe you don’t understand how to use the companies’ software that you are working for yet and there is some things you either want clarified or need more time on. If you were to just say that you understand everything, what does this precedent set? It tells people that you are okay to move on to the next thing and most often than not, whatever that “next thing” is, it most likely builds upon the previous task or requirement you should understand. Sometimes it is just better to be honest and let your team understand that although you may not currently understand what is happening now, you will be able to learn it. As long as you show you are able to learn the materials and keep up even when you are behind, you will always be valuable. Ask questions because not only will it help you, but it can often times help whoever is answering the question with something they may not have known about either.
Often times, as programmers, we will run into problems and will not know how to deal with these issues. Figuring out how to proceed is one of the most difficult things to do. What if the tool I am using doesn’t work? What if I am not fluent in a certain programming language to understand how to overcome a certain bug or fix a certain algorithm? These are all questions that concern us. The Dig Deeper method is very helpful in that it tells you to not just take everything that you learn for face value. Although tight deadlines and code maintenance may be daunting, you should always try your best in order to make sure that the code is clean. What we mean by this is that if you look up tutorials on how to do a certain task, those tutorials may have helped you solved the issue, but they could also have set you up for a lot of issues in the future. The tutorials may have cut corners or not complete things as efficiently as they should.
I really like this idea of Digging Deeper because we often try things sequentially that we find and just hope that the first or second method works. And if it does work we tend to just stick with it without even batting an eye at potential issues or large overhead that can carry. By completing tasks fully and really understanding problems inside and out, it is good to check multiple sources or tutorials. Code maintenance is huge aspect of live design programming. If you were to just look up random tutorials on how to do certain things for your code, you can get confused. You could look sup so many tutorials for each problem and eventually you won’t even be able to understand what does what action in your own code. And at that point, is it even yours? Being curious and making sure that you understand your code in a meaningful way will help you succeed and make further improvements to it. And the nice thing about this method, and many other methods, is that they don’t only apply to programming, but actually working with your team.