First blog post

This is the post excerpt.


This is your very first post. Click the Edit link to modify or delete it, or start a new post. If you like, use this post to tell readers why you started this blog and what you plan to do with it.


Expose Your Ignorance

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.


Dig Deeper

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.

Be the Worst

The pattern of Unleashing Your Enthusiasm is a very interesting pattern in that it teaches you how to deal with plateauing skills and what to do next. Becoming better at something is something that most people who are looking to improve try to accomplish. The difficult part is getting to that point. Often times we reach a point where nothing else seems achievable and all that was there to offer has been taken or learned. However, this is usually never the case. In fact, there can always be things to improve on – no matter what it is you do. One thing that you should teach yourself is that it is okay to be bad at something. If you compare yourself to others, that’s one thing. But if you compare yourself to others as a means to improve, that’s the important part. In order to get better at something, you need to find people that are better than you at it. This is just a basic fundamental of not only programming, but even sports. Boxers don’t just beat the best of the best in their first, second, or even third try. It takes them months or years to even try. But the more times they get knocked down, the more they learn. This is especially important in teamwork. By working with people who are better than you at something, you will naturally be obligated to perform better just because you don’t want to be the worst one. No one does.

I really enjoy this pattern because I have personal experience with this pattern. Whenever I am struggling with something, whether it’s programming, mathematics, or something else, I try to surround myself with people who better understand the content. By hearing them talk about certain things and by watching them do certain actions, that really helps me grasps topics better than anything else. Sometimes it’s hard to learn things on our own, but that’s okay. That’s because anyone can learn the content, it’s just a matter of HOW we learn. It’s a matter of HOW we perform certain actions that really push ourselves to our limits.

A Different Road

An important part of learning programming is the ability to keep learning and practice. By using ongoing practicing and learning, you will hone in on your skills as a developer and be able to solve a lot more problems that you may have thought differently about in the past. The Pattern of “A Different Road” says that you should find another path that has similar values with what you really are striving for. For example, if your family is important, you should choose some sort of path that follows that. Or if you value money or something else, you should reevaluate what exactly it is you are doing and ask yourself if it is something you truly want to do. Sometimes you may want to do one type of job but later find out that it is not as fulfilling as you once thought it was. This can lead to discouragement because it can get difficult. An example that the article used was how getting back into something can be difficult after leaving the first time. This is an important aspect tot he article because of it’s real world application. If you like to do something, you should really consider what exactly it is that you want to work for or work towards.

I found a lot of things that were interesting in this pattern. One thing that I would was very important was be able to know when something should change. If something seems like it would be unsatisfying to me, I should change it because it could hinder my ability in that field if I keep trying. This really made me think about my intended profession in ways that can potentially effect the places I choose to work at in the future. I definitely agree that although sometimes something may seem like a good profession, it may not always be stimulating to what you can truly apply yourself to. Trying different things is going to be very important and can be difficult, but it is that first step to make a change that will create all of the difference in the future.


Apprenticeship Patterns

Throughout our career, we will be faced with various tasks and situations that will require problems to be solved using various different resources. Some of these resources we will be a challenge in themselves because they may not be easy to learn or obtain. It’s all about picking something and sticking with it. Whether or not this is an idea, a programming language, or something else, it is always important to understand core concepts of ideas in order to completely fulfill them for a certain task. From the reading, there are various definitions of certain professions that can actual alter what we do based on it’s meaning. For instance, the reading talks about the terms apprentice, journeyman, and master and their relationship with software. Not only did I find this a very intriguing distinction, but it really opened my eyes as to just how many types of different operations occur in software craftsmanship. The way that the reading described each of the roles really picked my brain in a good way. It made me realize that there are many things that go on in each of these roles that I would have thought to be redundant. For example, when talking about an apprentice, it important to recognize that it is not really someone who works under an “elder” or master of work. Rather, it is more of an actual process. This process is composed of evolving and finding ways to solve issues in certain situations. It is a way that makes you complete issues and tasks on your own using the resources available while not really relying on someone else. This idea on how an apprentice means a type of process makes sense, especially when looking at it through a software developer point of view. This is because it can be a segway into the Jorneyman and and later a Master. The while the Journeyman is discovering and maintaining focus to grow craft, this later evolves into the “final” tier, the Master. But what exactly is a master created with? Similar to the previous roles of apprentice and journeyman, the master takes on all the processes and situation handling of those and finally gains the skill the enhance the skills of others while also figuring out new skills that can surpass your currents. All of this combined is plays a huge role in the later chapters of 2-6 where it discusses where to start, what to do, how to self motivate and much more. But where should you start?

One of the hardest places of tackling any task is the beginning. I agree with how the book approached this topic. Basically, what the book is telling us is that you should pick something and just stick to it for a while. If you need to solve a problem, you should have at least one language that you can be proficient in. By starting with this, you will have a basic building block for working on other task and to familiarize yourself even further when it comes time to working on other projects and/or jobs.  This chapter, Emptying the Cup (chapter 2), seems pretty relevant to me because I often have this issue. Often times I  have trouble choosing a starting position for tasks and don’t know where to begin. But after reading this chapter, the most important thing to do is to just try and stick with one thing and prevent yourself from trying to do multiple things at once and try to do one process at a time.

Automated Software Testing the Future?

When we think of AI, we usually think of robots doing certain actions that can replace basic human actions. Sometimes these actions aren’t basic at all. Development timelines have also changed drastically. This Forbes article talks about how AI can potentially take over testing phases due to the shorter time-frames for gold standard releases. With more and more companies releasing software, there will naturally be more competition. Not only is the competition driving this push for AI software testing, but also efficiency. Another thing that drives a push for AI software testing is cost structures. A lot of companies are based on certain cost structures which can heavily impact the quality of a product. With the amount of testing needed for a product to be in working conditions, you may need a lot of people per team to test software. Software testing AI seeks out to have this issue resolved or at least assisted. But, the main reason that AI in software testing is mainly due to narrow constraints of time. Since deadlines are always being set shorter and shorter while standards are being set higher and higher, it seems like the logical solution is to find the easiest and most effective way to combat these restraints

This is an interesting topic because it’s something that you wouldn’t really think would make much sense. If you development an AI to test software, then this could still potentially leave the software vulnerable to bugs. This is due to the fact that there are added variables and “middlemen” added into the equation if you have automated testing. Now, not to say that AI testing is useless, as it is probably extremely efficient at testing a lot of smaller things at once, however it seems like it could be added overhead. New roles would have to be assigned for teams just to test the software for the AI that is testing the software. In concept, AI testing seems like a great idea. However, there are bound to be bugs and whether or not it is worth the risk and cost to implement AI software testing is ultimately up to the companies do it. It is a very unique topic and will be interesting to see just how companies will implement this in the future.

Article: https://www.forbes.com/sites/forbestechcouncil/2018/12/17/ai-in-software-testing-will-a-bot-steal-your-spot/#63c50ce36710