In his post Back-end Development vs Front-end Development, Mikke Goes explains the differences between back-end and front-end development. He also goes into detail about the places where they intersect. Mikke also speaks briefly on combining both areas of development into what is known as full-stack development.

Back-end development concerns itself with the storage and manipulation of data. For example, when you log into your email, your browsers sends a request to the server to return all the information concerning your account, such as your settings and inbox. The mechanisms behind the storage and transferring of this information is the back-end. Back-end development concerns itself with the parts of a program you don’t usually see, but does a lot of work behind the scenes.

Front-end development finds its responsibilities mostly in the visual aspects of your program or application. All the buttons, text, and input fields on a web page are designed by front-end developers. This gives the users ways to interact with all the information stored in the back-end, creating an interface that bridges the gap between the client and the server. Both the functionality and appearance of web pages can fall under the duties of a front-end developer.

Full-stack development puts it all together. This is an understandably powerful position to operate in, as working on both the front- and back-end together ensures that they will be designed with each-other in mind and written properly and effectively. In CS-343 this semester, we have to work on a project where we are effectively full-stack developers. It is challenging to have to work on both at the same time, but I think working on one helps your understanding of what needs to go on the other end to tie everything together.

Front-end and back-end development are both important concepts. A web application isn’t going to exist without one or the other, and both are ultimately just as important to the end result as each-other. The differences are apparent, which is why it makes sense some people make a living doing one or the other. Ultimately, Mikee makes a good point that understanding both types is a boon to learning how to develop web applications.

From the blog CS@Worcester – Let's Get TechNICKal by technickal4 and used with permission of the author. All other rights reserved by the author.

In my Software Quality Assurance & Testing class, we recently did a group-based code review of a simple Sir Tommy Solitaire program that my professor wrote a few years ago. It was a really fun and interesting group activity that I enjoyed quite a bit, so I decided to look more into common Code Review practices to get a better understanding of how to conduct them in a better way. This article written by Trisha Gee I found on DZone.com was a great resource for learning more about them.

First and foremost, the most important thing to remember when conducting code reviews is that your job is to view the code within the parameters of the project you’re working on. For example, if your company uses Checkstyle and prefers Google Java Conventions vs Sun Code Conventions, then the team must keep that in mind when reviewing code. All reviews must be viewed through a lens that corresponds with the vision of the project at hand.

When you’re actually conducting the review, what are the easiest things to look for? The article from DZone mentioned these four topics:

• Formatting: Things line curly braces, spacing, line breaks. 
• Style: Is the code laid out in a logical way (variable declarations near their usage, etc.)
• Naming: Are naming conventions upheld throughout the program? Are they descriptive enough?
• Test Coverage: Are there tests that cover the code and what it interacts with?

However, there are plenty of tools that exist to mitigate the potential errors which come from these easily spotted issues. Humans aren’t so great at noticing minute details — something that machines are perfect for. Formatting tools like Checkstyle that I referred to earlier will usually ensure that formatting standards are upheld, and tools like JaCoCo can assist test coverage (we’ve used both of these in class and it’s remarkable how helpful they are).

Really, the job of the reviewer is to focus more on the design choices and quality of the code. Not only should the code run, but it should be readable, maintainable, it should be written with good design principles in mind. Are any parts reused, are design patterns used in elegant ways or do they needlessly increase complexity?

I haven’t quite yet read through all of Clean Code by “Uncle Bob”, but from what I know it seems like many of the principles in that book are ones that should be deeply considered when conducting a code review. I think anyone looking for further elaboration on the topic of Code Reviews should read both the article I found on DZone (and other DZone material, frankly), and Clean Code — it’s as popular as it is for a reason.

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

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

This pattern is all about taking a step back, a deep breath, and fighting through the struggles you might be having. The authors talk about the roller coaster ride that an apprenticeship can become. They include advice about what to do when you feel like you aren’t making any progress and how to fix the situation. Essentially, I think the authors wrote this pattern for people struggling to learn new technologies. It can be scary to jump into a project that you had never been familiar with before and  the authors provide a confidence booster to help you bounceback. The authors say to set a time limit for yourself to go back and practice the things you already know and are comfortable with, once that time limit is up, go back and try to work through the new problems you might be having. Build up your confidence and keep the forward momentum going.

I didn’t find this pattern to be as immediately useful as some of the other patterns, however I chose this pattern because this situation can happen to anyone. I am sure that it can be very easy to become overwhelmed with a project that you are not entirely comfortable with. However, I don’t necessarily agree with retreating, even if it is only for a short time. I find that being resilient and stubborn can help you fight through your issues, spending consecutive time working on something can help you break through the obstacles that you didn’t think you could. I don’t really understand the actions the authors say to take:

“Pick something self-contained that you know really well and reimplement it. For instance, Ade likes to implement caching algorithms because they can range from the trivial to the highly complex. They also allow opportunities to reinforce his intuition about design and algorithmic complexity.”

For example, it is great that he likes to implement caching algorithms but what does that have to do with the project he is working on, assuming that it has nothing to do with caching? Going back and doing something you’ve done many times can certainly help build confidence but I also think it might be too much of a distraction to try and be productive. Overall, I think not giving up is the most important part of succeeding. If you need a break you could ask someone (like a mentor) to help you learn the process.

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

In this pattern, the authors discuss the importance of building what they call “breakable toys.” The context they present is one in which the apprentice needs an outlet for failure, so to speak, because in order to gain the experience needed to excel in the software development field they must make mistakes and learn from them. This can be difficult in a professional setting as management and other superiors may not be expecting failure from the new apprentice. Hence, making mistakes in the work environment can have negative repercussions. While it’s impossible to avoid failure in the computer science field, it can be somewhat contained by adopting this pattern and breaking things in a low-stakes environment where the only one effected by failure is the apprentice himself.

The authors stress the fact that the only way to progress in the software development field is to make lots of mistakes and even just flat out fail sometimes in order to learn and grow as an individual and as a software craftsman. The authors advise apprentices to make breakable toys which resemble what they might be building at work. This allows the apprentice more flexibility in design and a lot less stress when compared to the professional setting. One example of a “breakable toy” the authors suggest for apprentices is putting together a wiki. They go on to show that by taking on this type of project the apprentice can learn new things about a variety of topics ranging from “HTTP, REST, parsing, web design, caching, full-text search, databases, and concurrency.”

I have to say I certainly agree with the authors after reading about this pattern. Even before I read this I have been experimenting with “breakable toys” of my own. When it comes to learning new things within the field, I am a very hands-on learner so building things and breaking them are a must if I hope to gain new useful skills. Since I work in Security, some of the side projects I have going on at the moment are things like building my own firewall and deploying a Security Onion instance within my home lab in order to gain first hand experience regarding best practices for Network Security Monitoring.

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

This is the first pattern in chapter 5 of Apprenticeship Patterns which focusses on how to address the steep learning curve associated with picking up new programming languages and/or practices. The context the authors present in this pattern is one in which the apprentice has acquired a set of “basic skills” that must be improved in order to become a journeyman. They describe the problem as being that the basic skills held by the apprentice are insufficient for high-level projects that require a more extensive knowledge base and/or skillset. The authors use the analogy that up to this point the apprentice has been sipping information through a straw but the time has come where they must drink from the fire hose of information.

As a solution, the authors suggest apprentices should “expand [their] ability to take in new information.” To do this, the authors advocate for apprentices to not just read books pertaining to knowledge they seek to gain but rather utilize a number of resources in combination with the reading to increase retention and understanding. Some of things they suggest are signing up for Google Reader and subscribing to software development blogs, following “luminaries” on twitter, subscribing to online mailing lists and answering people’s questions, as well as physically or virtually attending technical conferences. The authors note that when the so-called fire hose of information is turned on it can be difficult for an apprentice to get other work done as most of their time will be taken up by the process of ingesting a plethora of new information. Hence, they recommend that this pattern should not be used for more than a few months otherwise it may have yield diminished returns by decreasing an apprentice’s development velocity.

I found this particular pattern to offer some highly valuable advise in terms of how to really push my development career forward. I think that I can actually put this pattern to practice after graduation as I am moving into a position that requires a strong understanding of python programming. Up until this point in my career, I would describe my python programming skills as being basic but in order to excel in my position I will need to acquire a deeper set of skills. After reading this, I decided that when I start my new job I will try to put my mouth to the fire hose information, so to speak, in order to gain essential knowledge and put myself in a position to excel.

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

Complementing and maybe even contrasting The Long Road pattern described earlier this week, A Different Road is a pattern about when you stop being a craftsman.

After a long time on your Long Road of being a software craftsman you will have to seriously consider your future in the career and the industry. And as you do this, you may realize you no longer wish to continue the life long journey of moving to software mastery. In this case, you move off the long road and take a different road in your life. We all are on our own life long journeys and this can take us in many different directions depending on the circumstances.

Other software craftsman will not hold it against you if you decide to move on to something else. I personally would never judge someone for deciding they needed to change careers or that this particular career is not for them. I would wish them the best.

And this different path can also lead back to the long road. It is not a clear cut thing. Life is flexible and can the path you take through it can wind around in interesting ways. People can leave the road of being software craftsman and later on realize it was a mistake or it suits them better now. And as the book states, and my personal opinion states, other craftsman would welcome them back with open arms. I would think nothing of it if someone left the field for several years to follow another dream or similar, and then coming back when realizing that that was their calling. I can see myself changing careers and fields in pursuit of my calling depending on how each turns out. As I have stated before, what someone desires in life can change even day to day, as can their goals.

The unfortunate reality is that some in the industry will look down on this, or look at it with suspicion. Mostly those in charge of hiring decisions, most unfortunately. But this is a minor hurdle that can be overcome. It should not dissuade anyone from pursuing what they believe is their path in life. This is something I also whole heartedly believe.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

The Long Road is an apprenticeship pattern that is much more focused on the long term than some others. The situation it is designed for is essentially your entire career path. A craftsman is someone who is wholly dedicated to their craft and improving themselves in this. Someone who holds a genuine excitement and skill for the craft. Because of this, the path to becoming a true master craftsman is one that focuses wholly on the craft. So what to do you do when the opportunity presents itself to you to gain a promotion or a new job that gives you a large raise in income or something similar, but takes you away from your craft?

The Long Road posits that the best path to being a true craftsman is taking, well, the long road. There are no shortcuts, no big jumps that can lead to mastery. And moving away from this long road to being a master is something that should be avoided. This goes against conventional wisdom that most people have, to take the biggest opportunity that raises your station in life when it presents itself. But this does not improve yourself as a craftsman.

The way to do this is to slowly, but surely, build yourself up. Use the other patterns and have a genuine desire to learn and improve. It will take a long time and could be arduous, but it is the sure path to mastery. And it has no end, a life long journey of steady improvement. Such a long journey presents itself a wide variety of possibilities, which should be kept in mind as one walks the long road ahead of themselves.

This pattern definitely has the ability to be controversial for some, because it does go against conventional wisdom. When choosing whether to follow it one has to consider what they truly want in the end. I agree that the best way to being a master software craftsman is not veering off the path of being a software craftsman. But do I stick to this path that stringently? Is my ultimate goal in life to become a master? This pattern forces one to look to the future and question what their ultimate goals are, and I’m still wondering. There probably is no straight answer, as desires change throughout ones life, maybe even day to day.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

The Long Road is an apprenticeship pattern that is much more focused on the long term than some others. The situation it is designed for is essentially your entire career path. A craftsman is someone who is wholly dedicated to their craft and improving themselves in this. Someone who holds a genuine excitement and skill for the craft. Because of this, the path to becoming a true master craftsman is one that focuses wholly on the craft. So what to do you do when the opportunity presents itself to you to gain a promotion or a new job that gives you a large raise in income or something similar, but takes you away from your craft?

The Long Road posits that the best path to being a true craftsman is taking, well, the long road. There are no shortcuts, no big jumps that can lead to mastery. And moving away from this long road to being a master is something that should be avoided. This goes against conventional wisdom that most people have, to take the biggest opportunity that raises your station in life when it presents itself. But this does not improve yourself as a craftsman.

The way to do this is to slowly, but surely, build yourself up. Use the other patterns and have a genuine desire to learn and improve. It will take a long time and could be arduous, but it is the sure path to mastery. And it has no end, a life long journey of steady improvement. Such a long journey presents itself a wide variety of possibilities, which should be kept in mind as one walks the long road ahead of themselves.

This pattern definitely has the ability to be controversial for some, because it does go against conventional wisdom. When choosing whether to follow it one has to consider what they truly want in the end. I agree that the best way to being a master software craftsman is not veering off the path of being a software craftsman. But do I stick to this path that stringently? Is my ultimate goal in life to become a master? This pattern forces one to look to the future and question what their ultimate goals are, and I’m still wondering. There probably is no straight answer, as desires change throughout ones life, maybe even day to day.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.