Author Archives: Thomas Clifford

Familiar Tools

Any project that doesn’t retread at least some old ground for you is one where you can’t effectively gauge how long it will take. This is the problem the authors identify in this pattern. The solution offered is essentially to have a set of tools you’ve already mastered and to get at least one of them in whenever working on something unfamiliar.

One pitfall the authors mention is the possibility of your tools becoming obsolete. If you’ve mastered something, it can be pretty uncomfortable to give it up, especially when the new alternative is something completely unfamiliar. This is why I think it’s always a good idea to be on the lookout for things to add to your toolbox.

Speaking of, I want to actually come up with a proper response to the action section in this one, for a change. The authors basically just ask you to reflect on what your toolbox is. I have a specific project in mind, which is a small game I’ve wanted to make for a few months now, but haven’t been able to with school.

Here are the relevant tools I’m familiar with:

  • The JavaScript programming language
  • The OpenGL standard (kinda)
  • Krita (an art program)
  • LMMS (a DAW)

The authors suggest five tools, but I can’t really think of another one that makes sense for this project. I think coming up with this list was clarifying in that it made me realize that I’m not entirely comfortable with most of the tools I want to use for this project. The project, for reference, will be a short narrative-focused game where a character walks around and talks to people. It will be embedded in a web page, which is why I’m using JavaScript.

JavaScript is probably the thing I’m the most comfortable with on that list, although only because I feel pretty good about procedural and object oriented programming in general. The other three things I’ve mostly only really dabbled in, particularly LMMS.

Something else I noticed writing this list is that there’s quite a lot that’s going into this project that isn’t covered by a straightforward list of tools, even if I were to take away all the non-programming parts of it. I think it highlights the fact that just learning the tools, while necessary to get things done, isn’t sufficient. You also need to apply them creatively.

From the blog CS@Worcester – Tom's Blog by Thomas Clifford and used with permission of the author. All other rights reserved by the author.

Stay in the Trenches

The pattern I’m looking at for this post is titled “Stay in the Trenches.” The problem outlined here is that success in programming has a tendency to pull you away from programming. The authors quote Pete McBreen, who says “as soon as a person stops practicing, her mastery fades.” This is a pretty succinct description of the problem at play here.

In this pattern we are introduced to a new skill, which is using increasing positions of authority to construct your own work environment in such a way that you don’t fall out of practice. It’s something I had really never considered. Even though I’m used to being complimented on my programming skills, I had never really imagined stable work in software development at anything more than an entry level. In retrospect, I’m not really sure why.

Unlike some of these patterns, I think this one is a lot harder to disagree with. It doesn’t offer many opinions on what honing your craft entails, only noting that you need hands-on practice to stay good at the job, and exploring ways of staying in that practice.

I appreciate the suggestion to leave an inflexible workplace rather than continue on while your practical ability atrophies. I’m not really sure if I’m on the same page with the authors most of the time, but this sentiment in particular is one I am pretty strongly on board with.

The only thing I’d add is that I think it’s a little narrow minded to think just of one’s own development of their craft as an individual negotiating with various employers. Aside from making it easier to negotiate, another benefit of organization between software developers that I think would benefit them uniquely is that it could be an enormous opportunity for the refinement of software as a craft in general.

Rather than the same debates happening over and over on an individual scale, we could come to shared conclusions and move forward as an industry. It would also be nice to have proper training the way most trade unions have, rather than kind of soaking things in on your own alongside a college course or some random tutorial you found online.

From the blog CS@Worcester – Tom's Blog by Thomas Clifford and used with permission of the author. All other rights reserved by the author.

Sustainable Motivations

In this section, we recall that the best motivation for programming is enjoying the activity itself. However, real life work conditions tend to get in the way of this enjoyment. The solution proposed here is essentially to stick it out for the sake of your long term goals.

I liked the quote from David Hoover at the end. I think it’s a pretty apt description of what it’s like to have fun doing meaningful work. I also really liked the brief description of Obie Fernandez’s career, in which he became much more successful and talented by diversifying his skills. As someone with a lot of different ambitions, I find it pretty aspirational.

As far as how this has changed my thinking, I’m not really sure how to or even if I want to integrate this idea into my career. This is mainly because I don’t really know what I want to do, exactly. I think I might want to generalize it a little more.

My takeaway then would be to have more general goals that guide the specific ones. I don’t think that’s really a good way of explaining it but I don’t really have anything better.

What I mean by that is trying to connect general things I want, like financial stability or a reputation for talent, with actionable goals and actual things I can do. I tend to struggle with tunnel vision sometimes. It usually takes some thought to recall that the class I hate isn’t just what I do day to day, but also part of my degree. While I think what I’ve said above sounds kind of trite, I do feel like this section has helped clarify my thinking.

I’m also not sure if I agree with the dichotomy the authors give here, of writing easy, fun code versus writing difficult, but financially rewarding code. It seems pretty backwards to me. Personally, I think solving difficult problems is the most important and most rewarding thing a programmer does. When I imagine a terrible, unrewarding software job, I imagine one with no difficult problems. A position where the only thing to do is stitch together various APIs with no room for creative solutions or much thought at all.

From the blog CS@Worcester – Tom's Blog by Thomas Clifford and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

My third and final sprint for my software development capstone has come to an end. Here is what I did, and my thoughts on it.

This represents my thoughts on this file after looking it over. There’s probably still room for improvement but I didn’t think it was the best use of our time.

Changed the API to swap out json for plain text, since we want to return a .csv file.

Removed this because the previous commit made it unnecessary.

Some minor restructuring of the API.

Fixed a typo in the filename of the .yaml file mentioned above.

I think everyone had a pretty good work ethic. While individually we may have struggled, we collectively knew what we were doing.

As far as things that didn’t go well, I think we’re still struggling with assigning correct weight point values and issue granularity. Most things I did felt either too easy or too hard for their given point values, mainly the former.

The issues we made mostly felt to me like they were too specific. Sometimes this meant they were too easy, but not necessarily. I think it caused unnecessary confusion, since what should be one task might get split up into three, done by three different people. There’d then be no way for any of them individually to check their work.

There’s the possibility of coordinating the issues so that it’s clear they’re dependent on each other, but I think it would be simpler to just have them all be the same thing. I wouldn’t coordinate issues in this way unless they were clearly separate tasks, but still related.

One thing I think we could have done as a team is coordinate more. I think communication was our biggest weakness. I always felt like no matter what I was doing, I was always kind of going off on my own. At the start of the semester, we agreed to take turns being the scrum master, but as it went on we focused less and less on procedural concerns. I think we could have benefited a lot if someone had stepped up to be the team leader.

As far as things I could have done to improve, I could research more. My biggest roadblock was not really understanding how all the moving parts fit together. I think I overestimated my skills a lot. Also, in the context of a college class, there’s a strong incentive to just do the bare minimum to pass, with any independent study taking away from other classes and out of school activities. I did manage to get a little bit of independent study about the tools we were using in, but not nearly as much as I’d have liked.

From the blog CS@Worcester – Tom's Blog by Thomas Clifford and used with permission of the author. All other rights reserved by the author.

The Long Road

The pattern I’m going to look at today goes like this: Our culture is fixated on success to the detriment of true understanding of the work behind it. Consequently, there is pressure to abandon the craft at the first opportunity in favor of chasing success. The authors argue that you should push past that pressure, with the understanding that if you keep at it there’s no one you can’t eventually surpass.

I think the initial point about how our culture values fast, seemingly effortless results is insightful. In my experience, this is a pretty significant hurdle to get over to get good at anything. It can be difficult not to compare yourself to an imagined prodigy out there.

Broadly, I think it’s good to set your own goals, rather than chase illusory culturally-defined ones. I already have my own goals in mind that aren’t exactly things everyone wants, although I have a slightly different outlook than the authors here.

I think the authors, although probably not intentionally, frame things that everyone should expect from full time employment as either incidental and unworthy of consideration, in the case of money, or even a form of failure, in the case of retirement. If it were up to me, I would be content to do any type of work, with honing my software skills as a passion project. I unfortunately need money to live though, and the easiest path towards it is to leverage my interest in technology. The authors seem to view the need to make a living as incidental and irrelevant, but I don’t really think it’s harmful to your skills to not dedicate your whole life and career to honing them.

The authors also have a kind of competitive edge to their idea of personal development, suggesting that through devotion to honing one’s craft it becomes “realistic rather than vain to think about surpassing people like Donald Knuth or Linus Torvalds.” First of all, I don’t think realism and vanity are mutually exclusive. And furthermore, I don’t think this is really a healthy attitude to have. Why should you care about your skill relative to other people? How would you even be able to tell that you’re better than someone? Speaking from personal experience, I think the need to be better than other people has the potential to be really harmful to your own development. At least, it was for me. To “surpass” someone isn’t really a concrete, actionable goal, and I think it’s illusory in the same way as chasing success in general. I think it’s better to instead focus on what you actually want in your life, and on the people in it as much as possible.

From the blog CS@Worcester – Tom's Blog by Thomas Clifford and used with permission of the author. All other rights reserved by the author.

Retreat Into Competence

The problem being discussed here, like many others in this book, is something that I think is intrinsic to any kind of professional development. It’s the sensation of being out of depth in your work, a feeling that creeps into your thoughts, slowly atrophying your confidence.

At first glance, it seems like something that shouldn’t matter. You either know what you’re doing or you don’t, right? Why should your feelings about yourself play a role? That’s how I used to feel, and I also used to be pretty abysmal at putting in the work to get anything done, whether professionally, academically or personally. As unpleasant of a reality as it is to deal with, we are not machines that can churn out code like a printing press so long as things are physically working. Something I’ve learned the hard way, which this article touches on, is that you need to be firing on all cylinders emotionally as well as physically in order to actually do your best.

The solution proposed here is to prioritize something you know specifically for the sake of rebuilding confidence, rather than simply productivity. This could actually mean sacrificing productivity in the long term, but the feeling of competence is critical. Even if you don’t think this would work on you, you’d probably be surprised.

You will not be an expert at every problem. The key to building your expertise is to connect things you can do well to things you can’t, and sort of expand your understanding from there.

For example, I struggled quite a bit with Thea’s Pantry when I was getting started with it. The whole ecosystem of tools seemed extremely unintuitive to me. The turning point for me came when I realized that everything my project was doing started with running the index.js file, similar to how in most programming projects you have a main file where the execution begins. First, I started familiarizing myself with Node.js, the runtime for the project. Then I started looking at the other tools we were using, listed in the documentation, and trying to see how each fit into the flow of the program, like how external libraries fit into a more conventional application. This took time out of my work, but that time was critical for building my understanding.

From the blog CS@Worcester – Tom's Blog by Thomas Clifford and used with permission of the author. All other rights reserved by the author.

Sprint 2 Retrospective

I did the bulk of the work for this sprint in one sitting. I haven’t really figured out whether I think this was a good idea or not. On one hand, changing gears is something I’m not great at and I try to minimize it as much as I can. On the other hand, I wound up being pretty burnt out on the project.

Here’s the first issue I completed. “Learning RabbitMQ” is kind of an ephemeral goal, so I decided to only look into what I consider to be the bare minimum of what we will actually need, which is essentially just the ability to put messages in the queue and take them out of the queue. I feel like I know enough about it to work with it and help get other people up to speed.

I’m sticking these issues together because I wound up having to do them at the same time. To refactor things in the backend, I had to at least make sure it ran without errors, and to do that I needed to sort out the dependencies so that everything being imported at the top of index.js was either removed or installed.

It wasn’t until after I finished doing all this that I remembered someone had already modified the backend server to get it to work, only on a different branch. While that kind of tunnel vision is generally a bad thing in my opinion, doing all this work enabled me to actually understand how this project works. Specifically, I had a breakthrough in understanding that the server is actually just a program with its entry point being the index.js file. My previous experience with web development lead me to believe that the actual flow of the program logic was obscured behind all kinds of layers of indirection and it is in my opinion a little embarrassing that I didn’t see sooner that that was not the case.

Finally, I deleted a directory containing a project from the previous developers that they were using to mess around with RabbitMQ. Not much else to say about that.

I also considered tackling the issue I wrote before about updating the documentation for every project, but I decided against it. Apart from being a little burnt out, I also figured that it’d probably be better to put it off as long as possible so that whoever tackles it can go into it with as much knowledge as possible.

Individually, I think my main issue is just a matter of setting aside time for this project. As a team, I think our biggest problem is the granularity of our issues, although it’s somewhat necessary considering our experience level and the nature of the project. While I struggle to put the work in, I don’t think the team as a whole has this problem. 

All that being said, I am kind of excited about this project now. I was initially skeptical of my ability to contribute to this project, but now I feel like I actually sort of know what I’m doing

From the blog CS@Worcester – Tom's Blog by Thomas Clifford and used with permission of the author. All other rights reserved by the author.

Confronting my Ignorance

This pattern is called “Confront Your Ignorance”. The scenario it is meant to address is when a programmer has gaps in their knowledge that interfere with their work. More specifically, they want to master skills and tools, rather than simply be adequate, yet are unsure of the first step towards that goal. Finding the first step or even admitting they need to find the first step is difficult, particularly in environments where there seems to be an expectation to just have already mastered things.

The solution provided is simple. Pick something you need to learn and then learn it. While it sounds simple, it is easier said than done.

An important skill that I have only recently started thinking about, which this pattern touches on, is the ability to know when you’ve learned enough about a subject and that it’s time to turn your attention elsewhere. Without mastering this skill, one might still go out of their way to study something on their own. In the absence of any clear goals, they may simply give up whenever they get sick of it. This is something I used to do a lot, and it led to situations where I had taken time out of my day to learn something, but the knowledge itself was too incomplete to be useful. I wouldn’t go so far as to say that it was wasted time, but I think it could definitely have been better spent.

Different people have different approaches that best suit them for filling the gaps in their knowledge. Something I think is pretty important for me is to figure out what my ideal approach is. I have some ideas. For example, I think I tend to prefer concrete examples, hands-on involvement, and at least a general understanding of how the whole system works. Figuring out what works for me in more specific terms would be a good idea also.

I tend to struggle to seek help from peers. In this pattern, the authors suggest working together to learn things, which is something I think can be fun, productive, and worth trying.

One of the core ideas here, which I will talk about in a future post, is the idea of two extremes when learning, which need to be avoided. In one, ignorance is kept totally private, creating an atmosphere where not being proficient to begin with is extremely discouraged. In the other, no attempt is made to prevent one’s ignorance from interfering with a team’s project. Straddling the line between these is another skill that I haven’t really considered before, but should probably get good at sometime soon.

From the blog CS@Worcester – Tom's Blog by Thomas Clifford and used with permission of the author. All other rights reserved by the author.

Reporting System Sprint #1 In Review

Today I’m taking a break from writing about software apprenticeship to post a quick overview of my progress in the first of three sprints I’m doing as part of a scrum team working on the Thea’s Pantry reporting system. This is my first time on a scrum team as well as my first time working with most of the tech stack involved here, so if it seems sort of unfocused, that’s why.

Here are the links to the commits I wrote during the last sprint:

Here I fixed a typo. I also made the repo and wrote a very bare bones readme file that this commit was addressing.

Here I copied some boilerplate from an example project.

Here I added scripts that make it easier to use docker-compose.

I copied some things from an example readme to the frontend readme.

I went back and changed the title of that readme to actually be relevant to the project.

I deleted a random file that I think someone was using for testing purposes.

This commit contains the bulk of the actual work I did. That being said, I didn’t really know what I was doing, and mostly just thoughtlessly copied stuff over for the sake of getting something out there. I noticed there were dependencies at the top of the file, and that they needed to be either removed from the file or added to the project in order for the code to actually work, although for the sake of time and for the sake of keeping the history clear I decided to just leave them in as they were. After the retrospective meeting, I think there’s really no good reason to keep the validator around when NPM serves the same purpose, although we might still put the logger to use.

So, the problem that has been burning in my mind the most was that I just kind of threw things together, being so unfamiliar with the system that I really didn’t even test to see whether my code worked. A big part of that is that we don’t really have anything functioning yet, but it’s also because in the specific area I was working on (the backend) I actually was a little rusty on how. I am from a background where I’m used to just having an executable file with a call stack that I can look at at any time, and the way this project is spread across multiple machines is something I find somewhat confusing.

We also didn’t take creating issues as seriously as we should have, in my opinion. We kind of threw it all on a few people. We should probably have discussed them for more than just the one class session, and the discussion should have been put in writing on GitLab so that there would be evidence of everyone having participated (a lesson I learned the hard way).

I think many issues were too granular. Many of the above commits were two-weight issues, which our department is using to mean that the task should take about one week. I did most of them back to back in one session, except for the last one, which took another session (in other words, it all added up to one single two-weight issue).

I feel like as a team we’re pretty good at putting the effort in, which is in my opinion the hardest part of anything. I think our biggest struggle is in communication, and I think that’s due in part to unfamiliarity with the project. Something we could try as a team is to pick five areas to research and assign one to each person. Something I could do personally is see if I can get the whole system running so that I can test it out and know what everything is for and what everything is supposed to do.

One final thing I’m going to do is proofread everything I write in this project, because a pretty significant number of commits up there are just fixing typos. I actually noticed another one as I was writing this post, which I’ll probably fix as soon as I post this. I don’t really understand why I made all these errors, since it’s not something I usually do. I suspect it may be because I was panicking when I did most of the work here. That’s definitely something to avoid in the future, since I feel it’s not conducive to programming.

From the blog CS@Worcester – Tom's Blog by Thomas Clifford and used with permission of the author. All other rights reserved by the author.

The White Belt

The apprenticeship pattern I’m going to be looking at today is called “The White Belt”, from chapter 2.

The use case for this pattern is when a programmer has reached a point in their development where the rate at which they learn new information has begun to decline. The proposed solution is to hold on to newfound confidence while setting aside newfound knowledge. This way the new knowledge has time to sink in before it is synthesized with old knowledge, allowing new information to flow more easily.

I liked the example brought up here of Dave, a therapist. He found greater success with his clients after approaching his clients with as few assumptions and as much curiosity as possible. I feel that this demonstrates that this is a useful general principle for learning, rather than just one for learning about technology. This is why I find this idea compelling.

Something I found insightful in a more practical way was the idea of suspending the use of idioms you are familiar with in favor of the ones that are considered “best practice” for whatever tool you are using. Even if you don’t necessarily agree with, for instance, the concerns that Java programmers focus on, understanding the community around a language is essential to understanding the language itself. “Emptying your mind” in this way can be especially helpful the more unfamiliar you are with the language you are using, like if you were moving from a procedural to a functional language, for example.

I think that with technology fields in particular, there is immense pressure to be perfect, or at least exceptional. It can be extremely difficult to sacrifice productivity for benefits that are not immediate, and even more difficult to risk looking like you don’t know what you’re doing. Still, this is a leap of faith one must take to be good at what they do. Having it said so clearly makes it easy to see my hesitation as kind of silly.

I think I’m also going to add the book mentioned at one point, “Working Effectively with Legacy Code”, to my reading list. Not much was said about it, save for the effect it had on one reader, but it sounds like something that I, personally, would be really interested in. 

Another thing I’m going to try at some point is the exercise about rewriting a program with different idioms. I want to take something very simple I wrote for practice once, like a program that converts between temperature units, and rewrite it in a completely different language with idioms that are totally unfamiliar to me. I’m not really used to caring about idioms in this way, so I feel like this is the next big step forward I can take as a programmer. 

From the blog CS@Worcester – Tom's Blog by Thomas Clifford and used with permission of the author. All other rights reserved by the author.