Author Archives: tanminhtrieu

The Software Craftsman Chapter 15 & 16 Blog (5/9/2017)

Growing up, I always thought you had to choose between making a difference in the world and having a career that pays really good. As it turns out, after reading this book, you can have both; as a software craftsman! I really enjoy reading this book throughout all of its chapters. There was definitely a good amount of valuable information but it was written in a way where a lot of important concepts were constantly echoed throughout the book; such as being passionate about what you do, always leaving the code you work on cleaner than when you first started and of course, realizing that its bigger than just you.

Reflecting back, I used to have the mindset of never wanting to share or collaborate with anyone else because I felt as though it was my code, and my code only. Now, I just chuckle at how ignorant and unknowledgeable I was. If there was only one concept I could retain from these readings, (not including passion) it would be the ideology that software projects are not just about us and our egos. To become better software developers (and better people overall) we have to think about the bigger picture. We have to make sure that the foundation of the code we create and work on is sturdy; that it will not come crashing down when we, the current developers, are no longer around.

I think one of the reasons why people shy away from legacy code is because the previous developers has created such a crappy foundation of code that we are afraid of moving or changing any piece of code due to the fear that everything is just going to come crashing down. But, it doesn’t have to continue to be that way. We have the power to change that way of thinking because we have the power to change the way we code!

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

The Software Craftsman Chapter 13 & 14 Blog (5/2/2017)

Thanks to chapter 13, this is now going to be my quote of the week (maybe month): “bad tests are worse than no tests at all”. Am I the only one that’s blown away at how beautifully true that is? I hope not.

Anyways, I enjoyed the author’s take on creating an environment and culture of learning within the workplace in this chapter. It’s quite simple really; people tend to be more passionate and driven about their work when they don’t feel as though it is “work”. Remember as a kid how you always hated to do chores or clean your room? Well, if you hated doing those things, will you be excited or looking forward to having to do it every single day? Probably not. Now take that example and apply to developers in the workplace. If developers don’t like or enjoy writing tests, most likely they are not going to look forward to doing it. Even if they end up having to do it, you can almost guarantee that they are going to put minimum effort into it. Creating a culture of learning fixes this problem because if you can get developers to love what they are doing or learning, they are going to love doing their “job”.

On a smaller side note, chapter 14 was a fun chapter. It describes all the possible types of developers you might encounter that opposes the idea of new tools or practices and ways of going about convincing them to give the new tools/practices a chance. I feel as though I am going to subconsciously assign all my colleagues one of the titles mentioned in this chapter when I get my first real-world job as a developer (hahaha)

Random but relevant ending remark: You know, in a strange way, it kind of feels heroic to be a software craftsman. They’re like the Superman of Software Development…

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

Sprint 6 Learning Reflection Blog (4/25/17)

This was officially the last sprint for this semester! It flew by a lot quicker than I thought it would. Even though each sprint was approximately two weeks long, it certainly did not feel like it. It felt especially short because it would take our group about two sprints for each issue so the time seemed very short and at times, we wished the sprint was longer because we wanted to be able to finish an issue within one sprint. Overall, we were only able to resolve one issue. For this entire sprint, we spent a lot of time choosing issues to work on. We would choose one issue that looks promising, contact a member of the AMPATH team for clarification or for assistance on how to fix the issue, and a team member would contact us back and tell us that the bug or feature has already been resolved in another issue. This happened to us 4 times! After the second time, it began to get annoying because we were wasting so much time on issues that were already solved!

If there was anything I learned from this sprint it would be how important it is to properly manage and maintain the issue tracker. AMPATH and companies in general can save a lot of time and headache with better issue management. If each issue was thoroughly examined, there wouldn’t be any unnecessary issues that are asking for fixes to something that another issue is already addressing. There shouldn’t be two issues that are asking for the same fixes; that’s counter-productive!

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

The Software Craftsman Chapter 11 & 12 Blog (4/25/2017)

Chapter 11 was a good follow-up chapter to chapter 10’s interviewing software craftsmen. After reading this chapter, i gained a better understanding of what type of company I would want to work for. The books makes an excellent point by stating that interviewers should test candidates according to the things they value and to what is important to the projects instead of asking close-ended questions that anyone can answer by googling the question. Although I haven’t been through a huge amount of interviews, I can tell that most companies care about the “technical skills” rather than the passion of a developer. I don’t know about you but I rather be a developer that doesn’t know much but is passionate and willing to learn, than a technically-knowledgeable developer who does not care much for improving his skill set.

Also, here’s the summary to the idea and basic solution of low morale. Bored developers become lazy. Lazy developers become unmotivated developers. Unmotivated developers start to not care about their jobs. When developers don’t care for their jobs, the company makes no progress. When the company makes no progress, employees feel as though they are not developing and are not making a difference. When employees feel this way, their morale dangerously drops very low. So, basically if you want to stop this vicious cycle, don’t become one of those developers who becomes “bored”. How do you do that? Invest in yourself, constantly sharpen your skills, and be a software craftsman. That way, you will always be learning new ideas and talents; there’s no way you could get bored from that!

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

The Software Craftsman Chapter 9 & 10 Blog (4/18/2017)

Chapters 9 and 10 were especially interesting because it talks in depth about recruitment and interviews; and what better time to learn about those concepts than a senior graduating in 1 month! I found it so relatable when the author criticizes the job description of companies who are asking for qualities that are not even implemented at the workplace.

I would search for entry level software developer positions and one of the requirement for applying would be +2 years of career experience. Like, seriously?! I don’t understand how companies who are looking for entry level software developers are looking for candidates with +2 years of career experience. Correct me if I’m wrong but entry level does mean “introductory” or “basic” right?!

Chapters 9 and 10 encouraged me to not just follow the money, but rather, work for a company you feel passionate about, Work for some place where you feel you are being heard and can truly make a meaningful difference! There was a line in chapter 10 that completely left me mind-blown at how true it was. “During an interview, it is important to understand that we are not begging for a job. We are doing a business negotiation.” This made me realize that you, as a developer, have something to offer. You are not “asking” for a job, you are negotiating how much you believe your skill set can be worth to employers!

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

Sprint 5 Learning Reflection Blog (4/12/17)

I can’t believe this is our last sprint! It went by so fast; it feels as though we are just starting. Overall it was definitely a good learning experience being able to collaborate with a real organization. Our group had a good conversation with our professor about this whole sprint experience with the AMPATH group and it kind of prepares us for what it would be like working for a company in the real world as a full-time job. Over the duration of 2 months we only were able to resolve one issue. By face-value it might sound bad, but we spent the majority of the time trying to understand the language of Angular2 and the framework of how everything operated. If you think about it, my experience with this is pretty similar to what it will be like when working for your first company; most of the time will be getting used to the coding language and the framework. Prepare to be doing that most of the time before you even begin coding anything!

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

Software Craftsman Book Chapter 7 & 8 Blog (4/11/2017)

Although chapter 7 was mostly review of concepts I already learned, I do think it’s important to at least restate the idea of the “boy scout rule” and the “broken windows theory”, which was mentioned in chapter 7 because it’s an important mentality to be aware of. The boy scout rule is to “always leave the campground cleaner than you found it” and the broken windows theory states that “the bigger the mess is, the bigger it will become”.

Something that I did find helpful in chapter 7 however was the idea that we should not follow practices just because someone said so. Like with everything else, we should take all agile practices with a grain of salt because each practice can be extremely efficient in some cases, but rationally useless in other cases so it is ultimately up to us as the developers to know when to use what practice.

Chapter 8 mentions that there are 3 main things that a craftsman should look for in each job; autonomy, mastery, and purpose. I think it is every developer’s goal to find a job that fits these three qualities, because if you did, then you would now be doing something you love to do, rather than doing something because it offers large paychecks.

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

The Software Craftsman Book Chapter 5 & 6

The difference between craftsmen and average developers was beautifully summarized within chapters 5 and 6. Developers are just people who write code. Craftsmen, on the other hand, are gardeners. And just like a gardener, craftsmen constantly tend to their code, making sure everything is working properly, and making the code clean and clear for other programmers to read. As simple as the concept of being a craftsman as opposed to a developer is, most programmers still do not strive to be one. I believe that because of that, we run into some many avoidable problems. “We don’t write bad code on purpose but we are constantly trying to find ways to justify it.” This sentence from chapter 6 perfectly expresses how I feel about the situation and honestly, I agree. Not even talking about computer science, I think that that quote can be applied in all aspects of our lives; we make excuses for things we want to do but “don’t have time for”.

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

Sprint 4 (3/9/17 – 3/28/17) Learning Reflection Blog

We are almost done with resolving our first issue as a part of the AMPATH team. Spring break was during the ending half of this Sprint so not much work was done during the break. Although the overall progression is pretty slow, it’s moving along at a decent (decent for an amateur scrum team) pace so I’m not complaining. Besides the first issue that we are close to completing, I started looking at another reasonably do-able issue from the Sprint Backlog so I am excited to start working on that issue once the next Sprint cycle begins. We don’t really have much to show for considering we haven’t completely “resolved” any issues yet and it’s been about three months already but it’s better than nothing. Like they say, slowly but surely!

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.

The Software Craftsman Chapter 3 & 4 (3/28/17)

Comparing “The Software Craftsman” book to the “Clean Coder” book, there is a good amount of material that overlaps from one book to another. Chapters 3 and 4 introduces the idea of what software craftsmanship is and the attitude behind being successful at it.

The most important and useful piece of information from these two chapters was the idea that “clients don’t pay professionals to learn; use your own time and money to get better at what you do.” We as professionals get paid for the skills we have to offer so it makes sense that it is our responsibility to keep our skills sharp and up-to-date. If not, we slowly start to become irrelevant and people will no longer rely on us because our skills aren’t as sharp as it used to be. If you want to be paid good, then you better have a good skill set to show for; don’t expect a promotion if you have nothing new to offer to your employer. Think about it, why would anyone pay you more money for doing the same amount / quality of work?

From the blog CS@Worcester – Tan Trieu's Blog by tanminhtrieu and used with permission of the author. All other rights reserved by the author.