Author Archives: fymeri

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.

A Different Road

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

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

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.

Retreat Into Competence

This weeks second pattern can be considered a bit of a counterpart to the first. The Deep End described going headfirst into a new challenge to get yourself out of a rut and advance your skills. But what happens if you go too far, like the pattern cautioned? What if you bite off more than you can chew?

This is where the pattern, Retreat Into Competence, comes in handy. It is in essence , as the name states, is a retreat from the challenge. If you take a challenge that seems to be impossible or you can not make any headway into, then the wisest course of action might be to simply take a break. Gives yourself a breather, but not just that. You want to not only take a break, but also invigorate yourself and bring back your confidence if you were close to throwing in the towel. So once you retreat, do something you are competent in. Change course for a moment and do something you know you are good at or enjoy. Then once you have realized how good you actually are, dive back into the problem with more energy.

By taking a step back, you can fling yourself back at the problem with much more strength. And by taking a step back and giving yourself some space, that allows you to talk to mentors or others you know that can help you. With advice, tips, and renewed confidence, actually solving the challenge before you becomes much more likely than continuing to bash your head against it over and over again.

Overall, this pattern makes a lot of sense to me. Throughout my life, taking a a respite from something that had me in a frustrated loop of failure, and then coming back, led to me succeeding soon after. This does not just apply to software craftsmanship, it is a pretty universal tip for problems. Retreating can even provide a new perspective that would be impossible to gain with the tunnel vision that usually comes about when focusing on a challenge for a very long time. I have also had times where the retreat becomes me giving up and never coming back too, like the pattern warns. It can definitely be a double edged sword, so take caution.

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 Deep End

This weeks first apprenticeship pattern is The Deep End. The main issue this one is trying to solve is essentially getting into a rut. When one is just competently doing their job for a while, they are not preparing themselves for the next step or improving themselves. They are not advancing themselves as a craftsman, but simply doing a competent job and nothing else. As it states pretty succinctly, bland competence eventually decays into mediocrity .

A software craftsman has to improve their skills and their confidence, they need challenges. By not taking challenges, advancing in ones career becomes difficult. This is something I myself have experienced, especially during my college career. This is mostly due to the varied classes taking up both my focus and time, making it difficult to fully devote myself to advancing my software skills. This fed into a bit of a negative feedback loop where I would get down on myself for not working hard enough on challenging myself or being productive enough, which would definitely not encourage me to do more.

As the pattern states, a solution to this is to simply force oneself into a challenge, that requires ones full attention and learning new skills. By forcing an ultimatum, essentially, where one either grows and succeeds or fails, growing becomes much easier. Also, in my opinion, having a new project in and of itself is a very motivating thing. Something new that you might not even know how to begin solving is very exciting. It is akin to a new toy, playing with it can be much more appealing. It is a bit shallow, but it is true. Also, by being challenged, it can rouse the pride of a software craftsman inside that might have slowly faded in the rut.

I agree with the text, it can be dangerous to go head first into a challenge or big change without any help or guidance. While a big, new project can be a change of pace that allows one to break out of a rut, it can also cause them to fail and further entrench them or worse. It is important to throw oneself into the deep end, but make sure there is a lifeguard present.

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 5 Retrospective

This Sprint led to a frustrating conclusion. Our group essentially completed the offline storage service, which incidentally does much more than just store data, but came upon some sudden issues.

Because the service itself can also store, retrieve, delete, and update data while offline to an offline PouchDB database, that actually just uses IndexedDB on chrome, I floated the idea of renaming it to an offline database service instead. The idea was accepted, but currently renaming is an easy step that can be implemented after we get it working.

The main issue that has appeared is a confusing and somewhat baffling error that suddenly appeared. My team mate, Connor, had made a number of new tests for our service that were much more comprehensive than our previous simple ones. Using the tests we could see if the service worked, not just by the test results but by looking at the database itself in chromes dev tools to see the documents stored when the tests ran. The put and get commands added documents to our PouchDB database and would retrieve a JSON object from the database. However, starting this week, it simply stopped working.

I am still testing our service in isolation from the larger project, while using the same tslint.json to keep the format required the same, to avoid needless complications. Last week, running ng test to run the tests for our service through karma could no longer successfully launch. It would fail to open the browser consistently. Looking up the issue, I decided to reinstall the node modules director of my project. This ended up working, but ever since then, the methods in our service stopped succeeding.

The most baffling part is that there seems to be no feedback or explicit error at all. The commands to put and get documents and such are promises with a catch statement, so any errors should be caught and then logged. No errors are logged and yet the commands themselves also do not succeed. By viewing the database itself, it became apparent that no documents were being put into the database at all. Adding several console log statements throughout the methods to see which parts of it were executing showed that the entire put or get promise is being seemingly ignored. The promise has 3 different outcomes, it being resolves, being rejected, or an error happening. None of the options execute, which was very confusing.

This is still an ongoing issue with our service that once we fix should mean we are done. Frustratingly, this issue has shown up in my team mates projects as well, which means there must be something that happened that made it seem as if it was executing flawlessly earlier or we missed something. More research is required to fix this, it is a road block currently. I also discovered the command used for the ng2-amrs project is ‘npm run test’ instead of using angular cli’s test command ‘ng test’. This seems annoying as difference is that ‘npm run test’ seemingly has to be used every time tests need to be run, while ‘ng test’ can be used once and the tests will reload and be rerun whenever a code change happens.

I also did some more research into promises in pursuit of a fix to the issue in our project. I now understand the format of the then method much more comprehensively. And researching the PouchDB Api some more, I suggested some changes to the tests to make them much better at testing if the methods worked.

As long as we can fix our major issue right now, we can essentially finish our offline database and use is to complete the offline storage task of the project. Also, in my opinion, will somewhat easily allow us or another team to complete the offline form storage task.

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.

Confronting Your Ignorance

This apprenticeship pattern is the flip side of last weeks pattern, expose your ignorance. Now you have to confront the ignorance that you exposed to your team mates and coworkers . You start simply by choosing one thing you do not understand fully, and then researching and working on it until you fill in the gaps in your knowledge about that tool or framework or some such. You work on fixing your ignorance on your own time, until a point where you decide to continue working on it or move to something else you are ignorant in.

This is a very necessary pattern for an apprentice, especially paired with the previous pattern of exposing your ignorance. They both need to go hand in hand for an apprentice to advance themselves as a craftsman. What happens if one uses one pattern but not the other?

If someone uses the expose your ignorance pattern without confronting their ignorance, then they do nothing but stay ignorant. Whenever you are tasked with doing something you are ignorant of, you simply state your ignorance and then… that is it. You just shrug and say that you ca not do it. Without ever learning about things you do not know, you can never advance as a craftsman.

However, while confronting your ignorance does lead to learning and advance in oneself as a craftsman, doing only that without exposing the ignorance in the first place can be problematic. If apprentices only ever learn in their own time without letting anyone know that they were ignorant in the first place, everyone would silently work on their own problems without ever asking for help. There would be no discussion of issues, or allowing others to help you get through something you are having a large amount of trouble with. The reason one exposes their ignorance is to gain help from those on the team more experienced than them.

This pattern made a lot of sense to me. The part of the pattern section that discussed what confronting your ignorance without exposing it is was like was familiar to me. In the past I had moments where I would try to work on a project on my own for a long period of time, and bash my head against a wall until I figured it out. Then realizing I could have just asked someone else for help and reduce my frustrations by an enormous amount. Nowadays I was always strive to get past my pride and ask for help, to avoid a lot of headache and to help myself learn more effectively.

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.