Hey guys! This site is going to take a slight change in direction for the next few months; it’s my last year of college so your girl is going to feature some CS content for classes.
Stay tuned for more!
Samantha Tran
P.S. Please excuse my double-intro.
From the blog CS-Series by samanthatran and used with permission of the author. All other rights reserved by the author.
Hey guys! This site is going to take a slight change in direction for the next few months; it’s my last year of college so your girl is going to feature some CS content for classes.
Stay tuned for more!
Samantha Tran
P.S. Please excuse my double-intro.
From the blog CS-Series by samanthatran and used with permission of the author. All other rights reserved by the author.
Chapter 11 is titled “interview anti-Patterns”. This chapter talks about the wrong processes to go about conducting an interview as a developer. They should avoid doing things like being a smart-ass interviewer, using brainteasers, asking unnecessary questions, and trying to seem superior in knowledge. After we’ve worked hard to find a qualified candidate, the last thing we want to do is steal the opportunity they have to shine. We want to convince them that our company is the best they can work for, because a good developer will also be looking for a company that is best for them.
Chapter 12 talks about the cost of low morale and how unmotivated people seem to represent that very well. Unmotivated people tend to destroy companies because this can change the motivation of other workers significantly. I believe that the attitude of the people you work with can have a huge impact on the way you work; they can either motivate you or suck the morale out of you. In this chapter we learn that people become like that and that is mostly due to companies beating the passion out of developers. Manager and agile coaches are the last people to motivate developers because they are demanding and punctual about everything. The only person that can motivate a developer is another developer. Not just any developer, but a software craftsman that every team needs.
From the blog CS@Worcester – Adestin by adestinyblog and used with permission of the author. All other rights reserved by the author.
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.
Chapter 7 addresses a number of technical practices such as TDD, pair programming, SCRUM and their usefulness in improving our software delivery process. These agile methodologies are about delivering value to customers in the shortest time frame possible. Even though these practices are very effective in the software development process, it is difficult to convince manger to adopt them. Many companies do not use these practices because they fail to identify why they need them, when to use them, or simply does not believe that they are effective. It is not easy to get developers to adopt to these practices because there is a learning curve and it will take some time to understand. To figure out which practices to use, first we must know what area we need to improve and what we are trying to achieve.
Chapter 8 is titled “The long Road”. This chapter is perfect for aspiring developers because it talks about what to look for when choosing our careers. It summarized the career requirements into three things autonomy, mastery, and purpose. Having a successful career is not easy; we must figure out where we want to be and work hard to get there. We must treat every job as an investment to craft the career that will makes us happy. And if you are among the ones that do not know where they want to be, this chapter has a lot of suggestions to create options that can help decide the next step. Things like attending conferences, blogging, studying new things, and networking with other developers and business-people can open a lot of doors. Our career is important and carefully crafting it is the best way to reach where we want to be.
From the blog CS@Worcester – Adestin by adestinyblog and used with permission of the author. All other rights reserved by the author.
Chapter 5 of The Software Craftsman titled “Heroes, Goodwill, and Professionalism” essentially covers the communication between the client and the programmer.
There is a limit to satisfying the clients needs. From their perspective, they are not aware of how difficult and elaborate the process for a software project is. They usually have a demand and expects immediate and accurate results because after all that is what they pay us for. However, how we handle situations like this in this field is what determines our level of professionalism. It is our job to communicate with our clients and say “no” when they have unrealistic requests. We need to be upfront on what is possible, what is not, and set realistic deadlines so we can have enough time to work with no pressure. If we fail to communicate, then we end up looking unprofessional.
Chapter 6 is title “Working Software” and it is about keeping the quality of our software as polished as it can be. We must never sacrifice quality for the sake of meeting a deadline; that is bad practice. Our software must be written well enough to adjust to changes, otherwise we will become “hostages of our own software”and that will hinder the business progress. This makes perfect sense because as technology advances, our software needs to be able to adapt quickly. Adding new features should be implemented into with ease if we have good quality software. I like how Sandro relates code to a garden. He mentions that ” with basic and regular maintenance, the garden will always look great but if we neglect it, even for a short period of time, it will require much more effort to make it look good again”. I think this comparison accurately describes how we should treat our code. The same thing can happen to our code if we neglect it; it will deteriorate or loose quality and will require more work to regain quality.
From the blog CS@Worcester – Adestin by adestinyblog and used with permission of the author. All other rights reserved by the author.
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.
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.
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.
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.