This pattern seeks to solve the problem of skill gaps that are making daily work more challenging.  The authors propose that software apprentices suffering from this issue attempt to actively learn the missing pieces.  This could take different forms — they suggest reading tutorials/FAQs, constructing small low-stakes projects, and/or involving other people that are either experts in the area or trying to learn the same thing.  They also suggest keeping a list of these skill gap areas, and crossing them off as they’re sufficiently learned; this goes hand-in-hand with adding to the list as your learning exposes additional gaps.

This approach to learning really resonates with me.  My preference is to actively seek out knowledge, and I tend to learn best through hands-on practice.  I’ve already used a less formalized version of this when I taught myself Python: find a skill (in this case, a programming language) that I would like to learn and then give myself a project to work on that forces me to learn and use it.  There are three major additions (on top of the formalization) that I can take away from this pattern:

1. Involve other people, whether they are experts or fellow learners.
2. Don’t overuse this pattern to the point where it causes problems for others; I only have so much time.
3. Balance learning with introspection.

The first point leads to the creation of a learning community, and extends both the resources and benefits of learning.  I know that I have a tendency to want to do everything myself, and while independence isn’t bad it’s also important to not always be reinventing the wheel.  I also enjoy sharing my knowledge, and it makes sense for me to seek that out in a more mutual way.

The second point is also something I run into often, and partially extends from the first.  I really like to build things from scratch and see how they’re made.  However, that tendency can also lead to excessive use of time and energy for what should be a simpler project, or the preference for my own solution over another (quite possibly better) one that’s already been written and vetted.

The third point encourages me to set up a cycle of learning and introspection; crossing items off of the list and then adding more to the bottom.

While actual checklists are not a tool I particularly enjoy using, this pattern has leaned me towards perhaps keeping one (and actually updating it).  That, I think, is where I’ve found the most value in Confront Your Ignorance.

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

You can find more information about A Different Road pattern here: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch03s08.html

This passage is very quick and to the point. The authors emphasize that you should continue to follow your own map. Even if this new map brings you into an adventure you have never thought about doing. The authors ask just one thing, bring all of the knowledge and processes you’ve learned with you. Being a software apprentice means that you can look at problems from different perspective and use the tools and knowledge around you to excel and progress further. This way of thinking is not only useful in software development, but everywhere else too.

My favorite part about this pattern is that the authors understand that sometimes life can be strange. I enjoyed the example “…Ivan Moore, Ade’s mentor since ThoughtWorks, he described how he went off to a Greek island for six months to become a windsurfing instructor after his first IT job.” (Oshineye, Hoover). I liked this because it was so obscure. Who stops developing software to teach windsurfing? Well that’s the point. Everyone has different values in rewards. Regardless of what you want, someone else may want something entirely different. Maybe that windsurfing job paid HALF as much, but maybe money wasn’t important to Ivan. Instead he wanted to reap the rewards from enjoying life on a Greek island, the experience and the fun. These rewards could have been more valuable to him and you can’t tell him he is wrong.

The authors also tell you that leaving the field for some time could be risky as most conventional software companies see the break as a suspicious gap in your career. However, the authors also let you know that this- shouldn’t be the case. New experiences can help widen the perspective of one’s view. Leading to better understanding, communication, and team work.

At the end of the pattern the authors give you an action. All this is, is a suggestion on what to do if you are experiencing something like this problem in the pattern. The authors ask you to “write down some of the other jobs you think you would enjoy doing. Find people who are doing those jobs and loving it. Ask them what they love about it and compare that to the things you love about software development.” (Oshineye, Hoover)

At the end of the day, you should really be doing what you love and what rewards you, the best way you see fit.

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

Problem: You feel your job depends on you delivering a solution written in a specific programming language and of the same standard of quality as your teammates. Alternatively, obtaining a job in the first place depends on your proficiency in a specific programming language.

Solution: The text suggests picking a language and becoming fluent in it, as it will be the main language you will be using for the next few years to solve problems. It’s a difficult choice to make, especially when looking for jobs that may been looking for specific skills and languages. It’s “important to carefully weigh the options, as it is the foundation upon which your early career will be built.” One good way to gain experience and become fluent in a language is to actually have a real problem to solve, and to “seek out opportunities to create feedback.” Becoming fluent in a language allows you to start working more on test-driven development, allowing you to check your assumptions and aiding development of new languages.

This pattern has good advice, and it’s not the first time I’ve heard someone suggest working on one language and perfecting it instead of trying to learn multiple languages at the same time and expect to be fluent in each one. An interesting tip from the text was building a toy application in the language you’re trying to pursue a job with, one that your prospective employer would be able to access. Good learning experiences come from solving real problems, school gives you a good foundation to build upon and learn from the problems you solve in your professional career. Working in the field and running into real problems, the ability to work with other people and learn from them is a big part of gaining skill. I think Java would be a practical choice to become fluent in as it’s a high demand language that receives a lot of bad press but it running on 3 billion devices. The book also mentioned the community behind these languages and all the resources you have at your disposal. They suggest taking advantage of the support network you have and attending local meetings related to that language.

The post Your First Language appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

For this week, I chose a blog which talks about the future of software testing. Although these are just predictions by Ryan Yackel who is a senior sales engineer at QA symphony, they really seem plausible and get you thinking about where software testing is going to be in the next decade or so.

Ryan talks about how Everything will be blurry in the beginning and gets clearer after. what he means by that is the fact that agile software development methodologies are now becoming the standard and that will lead to a lot confusion and misconceptions. Because everyone is considered tester in a agile environment which is not true in a lot of cases, this really leaves testers questioning the severity of their role.  Agile methodologies’ popularity is increases among companies and they will soon have a better understanding and mastery of these agile techniques. Once this occurs, the role of a tester in a agile team will become much clearer. This leads to his next prediction.

Software testers expectation is on the rise and Ryan mentions that the expectation will be even greater in the future. Now, software testers need to expand their horizons and embrace new enterprise software testing tools and strategies. Just being knowledgeable about testing software is no longer sufficient. Software testers needs to be knowledgeable about software development, code functions, business logic, and technical competency. Testers a now playing an assertive role in guiding software quality assurance and development broadly.  As a tester, if you fail to adapt to these new higher level expectation, you will have a hard time making it through.

Ryan also talks about how the use of automated testing will increase significantly. It will be difficult for companies to maintain efficiency due to fast growing data in software development. Therefore, many companies will rely on automation in order to maximized their level of productivity. Ryan predicts that automation will become the default method of testing and all the challenges that holds automation testing from being the best way to test software will soon be refined.

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

This week I decided to read a blog post for my blog entry. The blog post I read is titles “Writing Clean Code” by Jason McCreary. Before finding this blog post, I’ve had a general and basic idea about coding and how it should be written, but I haven’t understood in great detail how to properly write clean code. The reason I chose this blog is to learn and be able to use the clean coding techniques on my future projects so it will be easier for other people read.

Clean code is extremely important in becoming a strong software engineer and when working in a team having clean code is a must so your teammates can understand your code. The blog opens up by saying that in more or less all software engineering jobs you will be working with a new code base at one point or another and that inconsistency is a big fundamental problem when working with different code bases. The author ends the blog by saying “In the end, coding is writing” and as a developer our responsibility is to maintain a consistently so it will make our code easy to follow when being looked over.

One major takeaway from this blog that I will apply immediately to my next project is using clearer names. Before reading this blog if I wouldn’t put much effort into naming things in my project but I learned that applying clear names not only improves readability, but boosts the context making the intent of the code easier to read. If I am to use clear names it will help the reader understand more quickly.

My goal is to become a software engineer and in the CS program sometimes it is hard for me to write clean code because I am focusing on other parts of the assignment or don’t have everything labeled to where my audience can understand. This article has given me ways to write clean, effective code in the future and I hope it can do the same for you.

Source: https://dev.to/gonedark/writing-clean-code

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

The podcast episode this post is written about can be found here.

This week I listened to a podcast in which the podcasters stage an argument between a 1990s “traditional” test manager and a modern test manager. I chose this podcast from about 4 I thought sounded interesting, because I wanted to know the current state of the industry and where we came from. It was enormously helpful in demonstrating the difference in how software gets tested these days compared with how it was done previously.

The one playing the role of the 90s manager explains how at his company, testing is kept largely separate from development. After software is implemented, it’s sent to software testers, whose job it is to find bugs. If they do find bugs, the project is sent back to the developers for them to fix. The second round of testing might reveal that the bug wasn’t fixed after all, and the result can be an endless game of ping-pong where the product doesn’t get released for ages.

Laid out in this way, it was clear how this inefficient setup led to the modern strategy of integrating software development and testing. The modern test manager explains that at his company, test specialists are embedded in the development team from the beginning, and the whole team is in charge of ensuring the quality of the product. The developers actually write most of the tests for their own code as they go along and end up finding most of the bugs. Test specialists may write more complex tests or write diagnostic tools, but mainly their job is to see the big picture and make sure that all the testing that needs to get done gets done. In fact, the modern manager says that most of the bugs that the team members who specialize in testing find don’t find them through writing typical tests or test automation, but through data analysis and looking at how customers use a product.

I gathered through listening to this conversation unfold that the basic idea of the modern setup is that catching bugs earlier makes them way less hassle to fix, so testing isn’t pushed to the end. Everybody in the team is capable of doing everything required for both implementation and testing, but they each specialize in a particular area. Going forward, I’ll make sure I don’t conceive of the testing process as entirely separate from the development process, but rather as something that goes along with code implementation in order to prevent headaches down the line.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

In this blog post, John Sonmez talks about “soft skills” and how they can help you become a better software developer. Here are some tips from the author:

1. Instead of trying to learn several programming languages at the same time it’s better to have one language that you know in and out, that you are comfortable writing.
2. Structure your code well by writing “good, clear, understandable code that doesn’t require a large amount of comments because the code itself is communicative.” – John Sonmez
3. Having a good understanding of object-oriented design and managing complexity as most popular languages rely heavily on object-oriented design and analysis.
4. Understanding how to create algorithms, and how to modify known algorithms to match your specific needs.
5. Understanding of data structures like arrays & vectors, linked-list, stacks, queues, trees, hashes and sets. These are important to know well, especially if you are being interviewed.
6. Knowing a development platform well is a good idea because some places design for specific platforms (PC, Mac, etc)
7. Learning a framework, or a complete stack. “A framework is simply a set of libraries that are used to develop code on a particular platform or on multiple platforms.” and “A stack is a set of technologies, usually including a framework, that are commonly used together to create a full application.”
8. Basic Database Knowledge, how to add, modify, delete and work with different database systems.
9. Source Control, understanding how to use tools like GIT.
10. Testing, more often projects are being created in small increments and tested as they go, this is allowing developers to catch bugs before they begin to cascade.

I chose this resource because I’m always looking for information on becoming a better software developer and want to become an asset to wherever I dedicate my work. Some of the information is general information but I do think it’s important to work on maintaining these core skills to improve the quality of your work. I learned the importance of working on knowing at least one language very well, along with knowing one platform very well knowing how to implement popular data structures, writing good algorithms and knowing when to use what. I learned the importance of object oriented design and how prevalent it is today. I learned about frameworks and stacks and what they are, and the importance of understanding how databases work. I also learned that more recently developers are being expected to know how to test their code, especially with agile testing.

The post The Technical Skills You Need to Have as a Software Developer appeared first on code friendly.

From the blog CS@Worcester – code friendly by erik and used with permission of the author. All other rights reserved by the author.

We recently went over how to test our programs and code using decision table testing. Decision table testing is extremely useful for laying out the requirements and conditions so that it is easier to comprehend and understand. This blog goes over, in detail, how to set up a decision table for a problem with an ATM and what conditions must be met to withdraw money. You can find it here: http://reqtest.com/requirements-blog/a-guide-to-using-decision-tables/ (I also used their pictures.)

I chose this blog to share with you because it relates directly to the assignment we were given for decision table testing. It has a section before the steps that give you the advantages and disadvantages to using the decision table which I thought would be useful to know and highlight. It also has every step for creating a decision table and is easy to understand.

“One advantage of using decision tables is that they make it possible to detect combinations of conditions that would otherwise not have been found and therefore not tested or developed. The requirements become much clearer and you often realize that some requirements are illogical, something that is hard to see when the requirements are only expressed in text.” – Ulf Eriksson, ReQtest

This advantage to decision table testing is a big one. Being able to easily cover every single case without being confused is extremely helpful. Essentially, decision tables give you a visual to go with the words.

The disadvantage to using decision table testing is that the decision table does not represent the complete test cases. Meaning you will have to think a little harder about how you write your cases.

With this being said, decision table testing can be used anywhere and this blog stresses that the tables should be constructed during system design so that the designers and testers are able to take advantage of the tables.

The steps are pretty easy to creating a decision table, the blog goes into more details with pictures (I recommend checking it out).

First, you want to figure out the conditions and actions in your problem. Conditions will be a requirement while actions will be the thing that happens if specific requirements are fulfilled.

Second, You want to figure out how many rules you are going to have. This is found by 2^n where n is the number of conditions in your table.  Your going to want to fill out your table with the different possibilities of conditions being true/false.

Third, you want to reduce your table by combining redundant cases. The “-” means that you don’t care if credit is granted sense you have enough money in your account regardless.

Notice how Column 1 and 3 were the same? Now they are combined.

This is the final table you would use to write test cases for this program! Overall, Decision Table Testing is a great way to lay out all requirements in front of you to ensure you do not miss any possible combinations of input!

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

Source: https://blog.codinghorror.com/flattening-arrow-code/

Stumbling across this week’s blog post Flattening Arrow Code by Jeff Atwood, I found myself reading about arrow code, which is self-explanatory. Basically, Jeff explains how he deals with Arrow Code, which is considered an Anti-pattern that is deemed a bad practice and should promptly be avoided wherever possible. The main benefit from refactoring is to reduce the cyclomatic complexity value, this value being used to determine how complex a piece of code is. The larger the value, the higher the complexity, the lower the value, the lower complexity. Another would be, from Jeff’s words “…to have code that scrolls vertically a lot… but not so much horizontally.”

When I look at code, I never suspect that there would be distinct patterns that are deemed as a bad practice. By reading about arrow code, I first thought, “Hey, I’ve seen that before” but left with “Oh, that is probably not the way to go about writing code”. In other words, I should probably learn this now. Anti-patterns, although the only one focused on in this blog is the arrow pattern is a great way to help avoid certain practices in the future. Even though, as of right now, I don’t understand most of what he said about converting negative checks into positive checks or decomposing conditional blocks into separate functions. Other things like guard clauses, being a conditional statement at the top of a function that bails out as soon as it can. Which I assume contributes to reducing time spent/resources spent running that function. Also, includes the idea of not sticking to the idea that there should only one exit point at the bottom of the function. Sometimes, it can be possible to exit at a different point rather than the very bottom. These two points, are good information as standalone practices.

Using this simple example, I can see that it is like YAGNI, KISS, Code Smells, etc., which means by understanding or being introduced to the bad practices early on. One, I am able to identify and solve the problems using common strategies already developed and tested. Two, I will be able to avoid putting myself into those situations where I would need to refactor the sections to be easily modifiable and maintainable. Although cyclomatic complexity is mentioned scarcely in the blog post, it reminded me of time complexity in algorithm analysis. Even though they are two different concepts, understanding that aiming for a smaller cyclomatic complexity value should result in a less extensive testing phase for the code. Which should save time, for future reference of course.

From the blog CS@Worcester – Progression through Computer Science and Beyond… by Johnny To and used with permission of the author. All other rights reserved by the author.