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.

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.

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.