Category Archives: Week-16

The Deep End

This Week I read up on the section called Deep End. This section talks about taking risks and not always taking the safe and easy route. With life it isn’t all about doing the bare minimum and playing it safe. Trying to cruise by in life by doing only what is needed of you. Also doing what you are comfortable with. This section has a story of a person who decided to take that leap of faith by accepting a new job that took him out of his comfort zone. He met with the CTO and CEO of the company he worked at and they wanted him to go to Lagos to work with a contract there and Lagos was rated the 3rd most dangerous city in the world and this would scare away a lot of people however he decided to go. When he started working there it was supposed to be a 3 month job however he stayed for nearly 2 years helping the client. He doesn’t regret taking that trip and because of the trip he has been all-over the west African country and now he is working in London. Because of the risk he took it opened his world by being able to experience different opportunity and meeting new people and go to new places. We can learn a lot from this because in life working on projects for companies we will not be doing things that we like all the time. There are going to be times that we would have to work on projects that take us out of our comfort zone and ask us to learn a new library or a new language and we would have to throw out everything we know and accept the fact that things change. Sooner or later we are going to have to make those hard decisions. But sometimes those hard decisions are just a test of our will to be able to move past those barriers that we have set in front of ourselves and to overcome the obstacles to become better and open new opportunity for ourselves. I think I will take this lesson with me in the future because there are going to be times that I am comfortable working at where I am at but when a new opportunity comes up where it asks me to move ½ way around the world and to work a new team. I will look back on this section and maybe take that opportunity and hopefully it would let me experience something new.

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.

Post #33 – Reflection on the “Rubbing Elbows” Pattern

This week, I will be writing the posting my final reflection on an apprenticeship pattern – the Rubbing Elbows pattern.  This pattern addresses developers who feel that they are more productive when they work alone.  The problem that arises for these developers is that they feel that their learning is stagnating because they believe that superior techniques are out there and their work environment causing them them to elude you.  I have had some problems working in groups throughout my college career, but I have never felt that my learning is stagnant.  I chose to write a reflection on this pattern because I think it could be useful in the future, if I ever run into this kind of problem.  Oshineye and Hoover provide solid advice on how to improve your learning in unfavorable environments.

The first piece of advice they give is to find ways to work on tasks with another developer, “side-by-side”.  Oshineye and Hoover believe that some things can only be learned while in the company of other developers.   Even if many techniques don’t require you to collaborate to learn, many ‘microtechniques’ do.  They believe that it is also beneficial to rotate programming partners, because you may find that, after some time, your partner has beome a troublesom one.  Your peers are not the only element conducive to a good working environment though; the physical location is actually important, as well.  According to Richard Sennett’s the Craftsman, an ideal work environment is one in which “absorption into tacit knowledge, unspoken and uncodified in words” takes place.  As many of us are aware, those kind of environments are few and far between, so ‘rubbing elbows’ with another developer is the modern day substitute.  Working with others exposes you to work habits that allow you to gradually refine your skill and extend those habits beyond software development.

The action they advise you to take, if you are somebody currently experiencing this problem, is to find somebody who has already expressed an interest in working collaboratively.  Try to coordinate with that person to meet once a week for a while and see how long you remain motivated.  If the business of your life begins to put a strain on your motivation, adapt and find ways to keep pushing forward until the motivation returns.  I found this pattern very helpful and I will utilize it in my future collaborations.

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

Thoughts on “Sustainable Motivations”

The Sustainable Motivations pattern is aimed at apprentices that are having a tough time sticking it out through the more difficult aspects of the craft.  These might not be constrained to the craftwork itself, but could involve management, handling stakeholders (practically it’s own craft, and probably deserving its own book and set of patterns), and just dealing with burnout.  Even if the apprentice hasn’t yet experienced a motivation deficit, they’re likely to encounter one at some point.  They also tell the apprentice to avoid “Golden Locks”, that trap a person in a position because it feels too good to give up, even though it does not contribute to longer-term goals.

Their solution is to commit motivations to writing, spacing some of them out over a few minutes.  They ask the apprentice to determine which of those are externally driven, which internal, and which may not be necessary.  The end result should be a list of five important things that motivate the apprentice, so they can “look at it when times get tough”.

Motivation can be tough for me.  I tend to be energetic at the start of projects or semesters, but struggle to find ways to keep going once the shine wears off.  One of my concerns as making my way in the professional world gets closer and closer to reality is that I won’t be able to sustain motivation.  I’m always worried that a month or two in, I’ll wear down and burn out and not be able to keep going even though I love programming.  As an apprentice software craftsman, finding ways to motivate myself (and the discipline to keep going if and when motivation fails) is probably one of the most important things I can do to set myself up for future success.

I realize while writing this that I don’t actually know for sure what my ambitions are.  I know that I want to spend some time in the software industry, if only to pay off my student loans and ensure that I’m comfortable.  Even if the motivation to do that is the only thing I get out of this pattern, it’s worth it.

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

Thoughts on “Concrete Skills”

This apprenticeship pattern seeks to solve the problem of the apprentice that wants to seek out and join a skilled team to contribute to and learn from (also, it pays the bills).  However, a truly novice software developer may lack the skills needed to contribute, and faces (perhaps fears) rejection.

The writers offer a solution and an action item to assist it.  The solution is to develop and maintain concrete skills, items that can go on a resume, get through HR filters, and convince a hiring manager that it’s worth it to take a shot on the otherwise unproven apprentice.  These include picking up new languages and technologies, and most importantly writing a project in them, especially if it’s something the apprentice can put on a repository site or their own personal site for potential employers to look at.  The action item (short of finishing a half-dozen personal projects) is to look at the CVs of skilled proffessionals, and to figure out which skills they have that the apprentice could learn.  This goes hand-in-hand with keeping one’s own CV up to date and figuring out which parts are likely to catch the attention of hiring managers.

I think that the development of concrete skills is one of the more valuable things that I’ve gotten out of my education, and I wish that I’d had more opportunities to develop some.  I think it’s really important for students to have opportunities to create projects that push not just conceptual learning, but force the development of concrete skills because they’re the best tools for the job.  I have also been lucky to have an employer that’s willing to let me work on software projects for the business which has given me a lot of experience as well.  I would add to this pattern a suggestion to find an external source of pressure to create a project that works and looks professional.

This is, I think, a pattern that seems obvious and is harder to put into practice than it might appear.  It’s easy to commit to doing things by looking over a CV and developing a list of skills, and harder to actually get them done.

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

Pattern : Study the Classics

Pattern Overview :

I believe this was a very short pattern but its content did not disappoint at all. It brought light to a few apprenticeship concepts that are needed in order for one to be called a master. Usually, developers are often self taught since the practice is so highly technical, they tend to gain hands on training  instead of the theoretical concepts. When this is the case, you as the developer misses out of the fundamental theory and structure of programming. 

Understanding the theory behind the practical actions gives you knowledge and proper understanding of how things are suppose to work. It also introduces you to acceptable and common practices in the field of development. Successful apprentices in the field spend time reading and understanding concepts from old software books. 

REFLECTION:

I truly believe and agree with the author concerning this topic. I know that reading not only keeps the mind busy but also explains how things are done and acquired. So the author advices to stick to classics since they provide and hold the most knowledge.  The Knowledge and understanding that is founds in these classics provide vital information that guides and  keeps up coming developers informed. With this being addressed, the author again addressed a con of this practice. He believed that reading old classics would cause one to be stuck in the old ways and forgot about new and upcoming technology. I  think this is invalid because i believe instead keeping you obsolete, the idea origins and knowledge get passed to you and you are in some way given a a head start on combining the old up with new modifications and designs. Once again fully understanding the methods and practices if the classics heightens your understanding of the craft and gives you the ability to build upon what you have read. 

Conclusion: 

Reading in it self is a great practice that keeps us alert and informed but reading about development introduces you to new arenas that had not yet being discovered yet. Long Lived books in the industry are often written by developers who take a lot of pride and pleasure in their ling of works and do not hesitate should an opportunity come up. 

 

 

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.

Nurture Your Passion

The apprenticeship pattern is another helpful one for the future. It is very similar to the other pattern talked about this week, but unlike the last one this week, Sustainable Motivations, it does not apply to the project we worked on over the last semester. Sustainable Motivations had to do with keeping ones motivation when faced with a task that did not cater to any of the reasons a programmer would be interested in programming. A project that is tedious, vague, or furstrating. This pattern, Nurture Your Passion, has to do with ones working environment instead.

In the real world not only are there hostile projects, but also hostile working environments. Corporations that do not care about you, or software craftsmanship. Ones that have abusive managers, demoralizing hierarchies, cynical coworkers, and project death marches. Things that kill a software craftsman’s passion in the their very craft. Things that can make them into one of the same people that contribute to that environment, even.

How does someone keep up their passion in the face of this? The answer is again looking to the future, as it was for Sustainable Motivations. You must look at the Long Road before you and visualize your road map for the future. You then have to see the conflicts between your current situation and the future one you want, and deal with it.

Your future may not align with the corporations, but you must do what is best for you. Project death marches that kill your passion? Stop playing along, leave early, at normal business hours. Do not fall prey to the hero mentality that will cause you to burn out in a couple of years, this is supposed to be a lifelong journey. Steer cynical conversations to positive and helpful topics. Try and steer unproductive meetings to something productive. Leave abusive ones. Work on making your hostile environment less hostile, and if you can not then leave.

The future they desire is what one should base their decisions on. You should never o off your Long Road unless you want to. Being pushed off of it is something that should be avoided at all costs.

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.

Sustainable Motivations

This weeks pattern, Sustainable Motivation, is actually is very appropriate given the project I and my team have been working on over the last semester. Though it probably would have been more helpful to have read this pattern much, much sooner in the semester. However, it will still be helpful in the future, so better late than never as they say.

Most people who program do it because at least on some level they enjoy programming and writing code. Thinking up solutions to interesting problems, implementing your ideas and thoughts into reality, solving a problem that is actually real with your own hard work, all of this motivates many people who get into programming. Also those that love technology and get excited at the prospect of using and learning more uses for it.

However, becoming a software craftsman and getting into the professional software developing world has its down sides. Mainly that most projects that others are willing to pay you to do are projects that someone needs to be payed to do. A project that is noting but tedium instead of problem solving. Or a project with very, very vague definitions. The gist of it being a project most people would not want to do normally.

Real life projects are not always glamorous. They can be frustrating, annoying, tedious, and just plain demoralizing. To the point that it might make some consider quitting, even those that are in the profession for nothing but the money. The key to overcoming this is to sustain your motivation.

The best way to do this is to consider the Long Road ahead of yourself. Just imagine the future before you and where you imagine yourself being. By doing this you can keep your motivation by focusing on a further goal than just completing the demotivating project before you.

While the project we have worked on this past semester was not exactly demoralizing, it was very frustrating. It involved attempting to learn many things I previously did not know. The process of constantly running into more new concepts every step of the way was frustrating, it felt like my progress and momentum hit a speedbump many times throughout. Despite that, progress was made, knowledge was gained, and at the end of the semester my motivations for becoming a programmer remain. I am still on the Long Road.

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.

Sprint 6 Retrospective

This was our final full sprint, the next one being only a couple days, and designed for gathering our thoughts, doing a pseudo post mortem, and presenting what we learned through the project. With it, we have essentially finished the project. This last sprint was mostly dedicated to a final breakthrough on on our service and the use of Promises.

In the beginning of the sprint, it was filled with some level of frustration. Our team lacked extensive or comprehensive knowledge on Promises, and asynchronous coding in general. This led to some blind trial and error attempts at trying to get our service to work correctly. The main issue was that our tests were failing in ways that were confusing. The main way being that the code in our service functions were seemingly being skipped, not happening at all, or just not returning what was expected or wanted.

Due to this, it was hard to tell where we were going wrong. Because of this, we eventually began researching Promises more to discover what the issue was. Eventually in one of our bi weekly, in person meetings it was brought to my attention by Shane Rookey, a team mate, that the issue was not that were doing something wrong in our functions. The main issue was the way were testing them.

With a promise, due to it being asynchronous, it is unknown when it is resolved. That’s why you use the ‘.then’ method of a promise. This method executes a function when the promise resolves, or when it fails. When the promise resolves, then do this, essentially. We would use PouchDB’s methods (.get, .put, etc), handle it in a .then, and then attempt to return the response of those methods. And then in our tests we would use a simple line of code to see if the response was what we expected.

However, because what was being returned from the methods was a promise, doing anything with it without using .then just does not work. We were simply using a line of code that expected the responses from the methods to have a field called ‘ok’ to be true. But that is a regular synchronous line of code. It has to be placed in the .then to work. Anything done with a promise has to be done in a .then. And attempting to return it also does not work, as after something is done in a .then, it returns another promise.

You can not just write the functions in the service asynchronously and then just go on as normal when handling them in tests and other services or code. That was what we did not understand. Once that was understood, writing tests and actually seeing if our functions, well, functioned, was much easier. Another team by this point had managed to get a service running that would take patient data and store it using PouchDB. We both met during the sprint and decided we should focus on getting tests running for the service while they focused on getting a GUI to display stored data up and running.

In the end, I felt more could have been done if we had some more prior knowledge. And also, if there was a bit more of a comprehensive guide on using promises and how to work with them. Some more comprehensive documentation would have smoothed things out. Our team will strive to document all these things for future developers that work on the project, which will hopefully aid in alleviating a lot of frustration.

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.