Category Archives: Professionalism

Capstone Project: Week 3 Reflections

Yet another week here and gone. This weeks reflections will be fairly brief due to it being the end of our sprint and having a weekend with nothing to work on. However, we did have a sprint retrospective this week due to our sprint completion! The retrospective went well. Our team has really great communication and that has helped us, so these retrospectives are just re-caps of things we found during the week.

One of the major issues we discussed was with our daily stand-ups. Due to us having to all do them remotely there leaves a lot open for loosely worded statements. We were using a lot of “I’ll try” or “I might get it done” and we wanted to clear up this language and be more precise. We found that two things happened when we became more precise.

  1. Others trusted what we said and knew we were going to get done what we said.
  2. We held ourselves personally accountable to truly get the things done that we said we were going to.

These two things I feel are very important for any scrum team!

We did our first real sprint planning today and I am very excited to start working with the AMPATH code and seeing what true professional software looks like!

From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.

Capstone Project: Week 2 Reflections

Another week, here and gone. Man time flies by when you’re having fun!

This past week the group and I made our first approach to google’s javascript framework, Angular 2. We dove right in with TypeScript and Angular2 by following the Tour of Heroes tutorial. This was pretty awesome but also very overwhelming. I found that it was quite a bit of information to digest in such a small amount of time. I, just as many others, learn best by solving problems of my own so I actually tried to tweak the tour of heroes a little bit here and there to learn a little bit more. As we dive head-long into the AMPATH project I am sure there will be times where I am completely overwhelmed, due to having to learn this brand new framework but something about that really gets me giddy like a child! I enjoy stretching my knowledge base and this is a for-sure way to do that.

In retrospect, one tutorial felt too short and I felt I didn’t learn enough. Myself and others in my group have decided to append our sprint, mid sprint to extend our Angular 2 learning. I have started reading the advanced guide to Routing on the Angular website to try and glean a little better understanding in this complex topic.

From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.

The Clean Coder: Chapters 3 & 4

Another week done and two more chapters of The Clean Coder read. This book has been quite enjoyable and it’s nice to have assigned reading from school that isn’t so “text-booky”. It’s nice to have something to read that is someone’s personal experience in the field of software engineering and hear about his successes and mistakes.

Chapter 3 talked about the flip side of chapter 3, saying yes and when to say it. I really enjoyed this chapter because it’s something I had make an conscious effort to approach in the past 9 months or so. I noticed at work I was using the phrases “try to get it done” and “might get it done”. I noticed this was simply giving me an excuse to take things at more of a relaxed pace and maybe not giving 100% to my employer. In May or June (I do not recall the exact date) I was moved into more of an IT infrastructural role at work. My first task.. Fully rebuild the LAN/WLAN structure of the facility. The president of the company told me this was of high importance to get this done a.s.a.p. and requested I estimate how long this would take. After some research and getting the things I needed on order I gave my boss a definitive date of 2 weeks until completion. Because I gave the president a definitive date and completed 2 days ahead of that date. He then started giving me tasks that we meant for my immediate supervisors because he knew that we would get a date things would be done by. I have since found that using correct language and giving good time tables creates better channels of communication and makes everyone in the organization happier.

Chapter 4 was the first time I had some serious differences in my ideas compared to Uncle Bob’s ideas. This was negated by the fact that he explicitly stated:

You will likely not agree with everything I say here. After all, this is deeply personal
stuff. In fact, you may violently disagree with some of my attitudes and principles.
That’s OK—they are not intended to be absolute truths for anyone other than me.

I find it funny that he had to mention 3 AM code. It seems to me that the general idea behind anyone who has tried solving a difficult problem with programming has come across this at least once in their efforts. I know I’ve talked with multiple programmers who all say the same thing, “If you can’t solve it, walk away for a while”. I’ve even told this to many programmers. It’s just a fact of life with any issue you can’t solve immediately. If you walk away and let your subconscious mull on the issue, 9 times out of 10, you’ll find the solution.

The one major thing I disagree with Uncle Bob on, is listening to music when trying to be productive. I am never more productive without music. I imagine this is something that changes from person to person as well. I know for my wife, she’s the most productive when things are dead silent. Now she’s a not a programmer and has never written a line of code but everyone has their own way of steadying their brain to focus in on a task. Part of my ritual to steady my brain is put on some music. Now I know that he also mentions avoid getting into the zone and this is something I already avoided anyways. But what music helps me accomplish is two things. It helps me set a rhythm to my work that keeps easily distracted part of my brain busy. Also, when I have headphones in it lets others know that I am baring down to get work done. In my office there are times I simply need to get stuff done and don’t have time for idle chit-chat. These are the times I find music especially helpful. If someone needs me they know they can simply come in to my area and I will almost always take my headphones off immediately. However, it puts up some sort of barrier that tells people I am too busy to chat about non-work-related topics.

All-in-all, it was another good week of reading what Uncle Bob had to say on Software engineering! I look forward to see what he has to say in Chapters 5 & 6.

From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.

The Clean Coder: Chapters 1 & 2

The Clean Coder, this is my first book by Uncle Bob (Robert C. Martin) that I’ve read. Clean Code was on my list of “to read” books along with many other great books for programmers and developers. I had been working through Godel, Escher, Bach: An Eternal Golden Braid, albeit at a sluggish pace and that is a great book as well. However, I read through the first two chapters of The Clean Coder this week and it is simply amazing. It’s a breath of fresh air from all the other “coding” books. What’s most interesting about this book is the fact that, at least with these first two chapters, the ideas extend far beyond just software development. His ideas of professionalism will essentially make any type of career better.

Chapter 1 began by talking about Professionalism. Uncle Bob’s main point in this chapter to strive towards professionalism was taking responsibility for our problems. He elaborated on this and really pushed the point of “Do No Harm”, and by this he meant strive create working and easily maintainable code. Obviously this is what we all strive for as programmers, but he went a step beyond that and began talking about making the responsibility of “perfect code” ours and ours alone. Don’t leave it to the QA team to find and report bugs, take that on yourself. Don’t leave it up to someone else to refactor your code to make it more extensible, do that yourself. I really appreciated this point, because sometimes I find myself slipping into the mindset of, “I don’t need to take care of that, it’s someone else’s problem. Even if I don’t have the answer 100% I should do my best to help the person reach the solution faster.

Chapter 2 talked about Saying no. This is something I personally struggle with. I am the kind of person who generally can’t tell people no – especially my bosses. I was bread with the mindset, from an early age, that when your employer instructs you to do something, do it. Now not to say this is a bad mindset by any means, but in the real world this can seriously hurt your career and your companies future.

My first major piece of “Software” the I ever attempted at building was a simple front end for a database that also had some data crunching abilities. I also had to design and build out the database. My company is not a software company but an environmental engineering firm so no one really had a clue about building software/coding. Fairly straight forward and easy to build project, for a Senior in his CS degree program. However, when I started this program I was in my first year as a CS student. At this point I had written small programs in languages like Java or Python, but each of these programs did simply CLI type functions and nothing too complicated. I think the most interesting thing I had done at this point was a Fibonacci calculator that used recursion and memoization. I hadn’t approached any problems that essentially required an architecture that used a front end as well as needed data persistence. I had no idea where to begin but I dove in anyways. I told my boss it was going to take 3 months or so to build something like this. I was going to work non-stop over the summer on this project to get it done. The end of the summer came and I felt I barely had anything done. I was probably half way done with the feature sets that had been requested but felt I was on a roll. When my boss asked when it wouldn’t be done, I responded with the fact that I was “unsure”. I wasn’t sure what more bumps I was going to hit along the way because I had no experience at this. He gave me three more weeks and he wanted it done. I said okay.

I got all the features done is this program and it’s still being used at my company today. But I get requests constantly to fix some bug because I didn’t have time to test it. Because I didn’t tell my boss “No I can’t finish it in three weeks”, I was left with an embarrassing piece of work that I always afraid to show people due to my unprofessionalism during the development of that project.

In summary, I am extremely excited about going through this book and being able to apply what I read to not only Capstone project but also to my day to day work life. I think that not only developers should read at least the first 2 chapters of this book but anyone who builds a product for a customer.

From the blog CS@Worcester – Tyler Lundstrom by CS@Worcester – Tyler Lundstrom and used with permission of the author. All other rights reserved by the author.

Professionals say NO.

I started reading this book for my software development capstone course entitled “The Clean Coder” and I’ve got to say, I’ve been enjoying it more than some other books I’ve read. The book is both informative but also has a casual feel to it because of all the stories and examples that the author uses. The first chapter of the book starts off with a key and important concept; professionalism. This makes sense because in order to be successful in a professional company, you need professionalism. Now for most this may sound trivial but from my personal experience, I have seen many examples that makes me question whether this concept is really that obvious to everyone.

Professionalism is summarized in the book as being responsible and accountable. Going into the second chapter of the book; a part of being professional is the ability to know when to say no. I truly feel as though this is such an overlooked idea because people always try to be the hero and save the day by constantly agreeing to tasks that they know cannot be accomplished. Now surely it may sound good to your employer or boss that you are saying yes to all these assignments but at the end of the day all you’re really doing is setting yourself up for failure which damages your credibility and in turn, ruins your accountability.

 

CS 448 Week 1 Blog The Clean Coder Chapter 1 – 2 (January 17 – January 23)

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.