Dig deeper is a very important apprenticeship pattern to remember throughout your career and especially one to pay close attention to early on in your career. It stresses that just writing a solution that you found online or just guessed until it worked is not good enough. It is important to know why the code solved the problem that you were having. You should also look as to why was this the chosen solution, why code A over code B. This will help you stand out at work as someone who is a more effective problem solver. This will also help so you don’t submit a project that is only half complete; maybe the question that was answered on stack overflow did not include a test that was specific to your work. If you do not dig deeper into your solution you may not realize this and turn in an unfinished project. When you only scratch the surface and just barely do enough to get by or even less than that work falls to others. There is a set amount of work that needs to be done for each project. Just because you do less doesn’t mean less work needs to be done, it just means that you are putting a bigger burden on the rest of your team that needs to complete their own work and pick up your slack as well.
When moving on from school I intend to make it a point to set aside time to review all the work that I complete as well as try to fully understand other parts of the program that I have a chance to see before submitting my work. I think this will be beneficial for a few different reasons. First it will help set an impression with both my peers and superiors that I am a thorough worker who puts extra effort into my code. More importantly though it will allow me to expand my knowledge and provide the best possible solution for the problem that I am presented with. It will help a well rounded tool kit that I may not only use immediately but could be applied in the future too. Doing this early on will create a solid foundation to build on for the foreseeable future.
From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.
This week I read the section called Expose Your Ignorance. This sections is something i can relate to very well. I am a senior in college and by that time many people would think that you would be able to program thing by yourself. You should know about at least 2-3 languages by now and have the knowledge to work in the real world however just like the section “White Belt” there are always going to be people better than you and you don’t know everything yet. It is still a learning experience and for me in the class that we are taking now the section we are doing for the project. Which is encryption services is still something I don’t know much about at all. Just saying that you know nothing about something would be better then you hiding and saying nothing. That is what a team is about. To help and encourage each other to do what you can do and that way you can help them when they need help. During hackatons that i go to when meeting new people if we wanna work on a project we all have to introduce ourselves to each other. We also have to tell people what we can and can’t do because if we depend on someone to the most important part of the project and they don’t have the knowledge to do it in the end we would not have a project to present. Also just because you don’t have the knowledge to work on the project you should not just sit around and do nothing. Take this time to learn a new language, download the library’s needed to work on the project, watch videos, and work with a project partner to see if there is anything you can do. Just like the section says people are more inclined to make themselves look competent then just to tell others that you don’t know what you are doing because there are people looking up to you for advice or employers looking to you for the knowledge. That is why this section teaches you that you that lying about knowledge inst worth it and to accept your faults and work on them another day.
From the blog CS@Worcester – The Road of CS by Henry_Tang_blog and used with permission of the author. All other rights reserved by the author.
Without exemplars of good practice to study and emulate, the Practice, Practice, Practice pattern only entrenches the bad habits you don’t know you have. If you never walk a mile in someone else’s moccasins, you may come to believe that all shoes are meant to have stones in them. So how do you find out if your work is any good, given that those around you may not have the ability to tell good code from bad?
The solution the text offers is to seek out other people’s code and read it. Start looking into applications and tools you use every day. It allows to you to learn how other professionals write code, and the thought process behind creating the infrastructure you’re using. When examining open source projects, it’s best to download the most recent version and preferably from the direct source so you can inspect the history of commits and track future updates. Learn the codebase and how the files are structured. Think about how you would have done things differently, and if maybe you should rethink the way you do something because someone might have a better solution.
This pattern has good tips on learning from the source. I liked the idea of starting with tools and applications you work with every day, I think starting with open source projects is a great way to learn how current professionals are writing code and what practices they are utilizing. You may find things you disagree with and things that make you re-think how to approach a problem. I think it’s also good advice to seek out others to read code you’ve written and have them offer feedback. It refreshing to know that so much content is available open source, and it can give people like me access to real working programs that I can learn and possible contribute to in the future. I like the idea of looking into sites like Git, Subversion, and Mercurial and learning how these projects work, and what design patterns and algorithms they are using. I believe reading and understanding open source projects will make me a better programmer, and will help me greatly in my professional career as I continue to add to my toolbox of best practices.
The post Use the Source 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.
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 is probably the most important pattern I have checked out in the book by Dave Hoover and Adewale Oshineye. The entire pattern is about finding a mentor/master that helps you walk “The Long Road” with more ease. Allowing you to grow and cultivate your skills into tools that will be used for the rest of your life. The authors make sure to note that since our profession is still relatively young, there aren’t many recognized “masters” of the art. However, your masters don’t have to be physically available to you at all times. Maybe you read a book about someone’s life who really interested you and you begin to develop a passion for the things the author enjoyed, that author will be your master regardless of whether you talked to them or not. They may even be deceased!
The authors go on to emphasize that just because you are the apprentice and your master is the master, doesn’t mean that they are the one and all-knowing god of coding. No one knows everything. Be free to opportunities and don’t only talk to your master, learn from other masters and expand your mind with knowledge. Lastly, this chapter reassures you that there is no real risk to looking for mentors. While it may be difficult, the payoff would be huge for you. The only risk is getting rejected, which really is not that big of a deal. Most top-notch developers had memorable mentors to help them along the way.
This pattern will certainly affect how I go about things in the future. I had never really thought about going up to someone and asking to be their apprentice or “assistant” but I could actually see it working. I could see someone at a new job being a mentor to me but I could also see myself going to volunteer on a separate project outside of work just to get extra practice and that sense of apprenticeship. I really enjoy the thought of having a mentor, so that may be one of my next steps.
From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.
This week, I will be writing a reflection on the “Sweep the Floor” pattern. This pattern addresses apprentice software developers that are unsure of their place on a new team but want to contribute to the team’s work and earn their trust. I chose this pattern mainly because the title caught my eye, but also because I think it could come in handy for when I begin my internship, working on a small development team, in June. Oshineye and Hoover provide solid advice on how to make meaningful contributions to a team by volunteering to perform simple yet necessary tasks.
Some tasks you can complete to promote the early success of the team might be maintaining the build system, setting up the project wiki, updating documentation, code reviews, etc. They describe these tasks as residing in the “edges” of the project where there is less of a risk of damaging causing damage to it. The reason that this pattern is called “Sweeping the Floor” is because it refers to the fact that, while sweeping the floor might seem like a mundane and tedious task, it is necessary to the upkeep of any building – and somebody has to do it. Simple and/or tedious tasks benefit not only the team but also you as an apprentice, because “chores” are often overlooked in academia but doing them fills the gaps in developers’ knowledge. Oshineye and Hoover raise an interesting point by saying that education means less than college-graduates might think, because everybody starts at square one when they join a new team and, as a developer on square one, taking on mundane tasks is very helpful.
They go on to explain some of the negative consequences that could occur when applying this pattern in the field. The first negative consequence could be that you might become the team’s “gopher”, the go-to person for mundane tasks, for the duration spent working on the project. A second negative consequence that could result could be that you no longer feel confident tackling tasks that aren’t like your regular “sweeping the floor” tasks. There is also the possible negative consequence that you don’t develop an appreciation for the bigger picture while “sweeping the floor” because you aren’t gaining a wider coherence. Oshineye and Hoover recommend that developers facing any of these negative consequences refer to the “Nurture Your Passion” and “Unleash Your Enthusiasm” patterns.
To implement this pattern, Oshineye and Hoover advise apprentice developers, who are new to a team, to tackle the tasks that everybody else would complain about. Not only should apprentice developers tackle those tasks, but they should also approach them with creative solutions to exceed their team’s expectations and make the situation fun and rewarding. I think this pattern will be a useful reference in my repertoire and I hope to implement it in the field, this summer.
From the blog CS@Worcester – by Ryan Marcelonis and used with permission of the author. All other rights reserved by the author.
Once again, i think we had a successful sprint this round. Once again we increased team communications and continued to form better team bonds. This is specifically because this sprints task required us to consult each other for things we have expertise in so we could build together what we needed to build. I this sprint we took upon quite a few tasks to get accomplished. Some of these tasks included taking the offline checking of the current ampath build and moving it to the outside of error checking and by doing that, figure out a way to fix the OnlineTrackerComponent bug we found in the program. Another that that needed to be done was establishing communication mediums with the AMPATH group and addressing some development issues we wanted to discuss with them. We needed to know if we had to worry about storing secondary and additional user login credentials offline. Knowing this would prove pivotal to our developmental Sprint. We were also able to create a backend of the new UI we were implementing using Balsamiq. Another task that was sought out this sprint was to update the HLD with local storage approach and add a checkbox to the user settings page to give option to store credentials locally. This task was taken by one of our teammate and although they were working on it alone, collaboration between the individual groups was needed because there were a lot of dependency issues.
From this sprint i learnt that sometimes not all the task we seek out to accomplish during the sprint planing is able to make it through the entire sprint. During the initial sprint planning, we had a talk about implementing a local database that would store and keep user credentials so for the few days into the sprint i began building the database base but as the sprint progressed and our team was able to communicate with the Ampath people, we realized that that extraneous part of building the database was not necessary needed. Instead understanding the encryption method of the user credentials would better suit us in our task of creating an offline login. Needless to say, i had to clear the drawing board and start again.
Overall i felt like this was the biggest lesson i could take from this sprint because i started building and spending time on it but since it was ruled out as not necessary, it almost seemed like i had wasted that sprint time. IT made me realize that in this software development industry, the product owner and the businessman have the keys and unless you ask them for it often you will develop and code in a backdoor without even realizing that your design grew old in the specifications. Establish a good and frequent communication method with the people overseeing the demands and design of the project serves as key in become a good program develop. It makes no sense to design and solve a problem with no longer exists in your scope of work.
From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.