Category Archives: Week-16

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.