Category Archives: Week-15

Rubbing Elbows

The first question that interviewers ask candidates these days is about team experiences. They look at many different factors but working as a team is always an important one. If that person cannot work with a team, that is going to be a red flag. There is a saying that “if you want to go fast, go alone. If you want to go far, go together”. Team work gives people the ability to improve their communication skills, to be more efficient in building products and also to motivate each others.

We may have mentors and kindred spirits that we meet along the way, but people tend to think that software developers usually work independently. The problem is what if the product has reached its limit, the learning is struggling and the feeling that there are superior techniques and approaches to the craft that are eluding us.

The best solution is to find a way to sit down, have a talk with colleagues, and work together on a project. There is always something that we could learn from each other. The case that was mentioned in this “Rubbing Elbows” is Dave, who found an ally in Roman and then literally rubbed elbows over lunch as they learned together about technologies like the Ruby programming language and Eclipse plug-in development. Even though Roman could have not been that kindred spirit but Dave would still have benefited by working next to a talented programmer. There is always a certain technique that we could learn from others because we are not perfect. Therefore, it’s critical for us to be open to learning and willing to take it in. While paring programming can be an excellent technique for learning, it’s a complex activity and is not always an inherently positive experience. And sometimes it is a pain. If we feel chronic behind, week after week, and we’re beginning to despair, then it’s time for a change. The rotation may help jiggle us out of trouble. Ping-Pong programming to increase our participation is also a good way.

The final thought is to find someone we know who has already expressed an interest in starting an open-source project. Spend one day or an evening a week working together on that project. See how things would go, and seek motivation from each other. If motivation never return, it is up to us to seek new partnership where we can learn new thing. Because the best way to stay in workforce of this industry is to keep up with new technology.

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

Reading List

Summary:

Reading List pattern recognizes that as software developers/apprentice we need to start learning the next thing, but how do we choose from the vast ocean skills and information available. The pattern recognizes that its not only hard to decide which language or area we want to master next but also which book or books will be the most appropriate for that step. The pattern recommends the simplest possible implementation that is to create a reading list. Reading list could be just a text file with a list of all books that have been read, books currently being read and books we plan to read.

Why this pattern?

Reading List pattern helps answer one of the most difficult questions, what next? Now that I am done with college, the obvious thing to do next is to find a job. However, the list of the things I have barely managed to scrap the surface of in the last year, specifically the two capstones, its like I have a bitter after taste in my conscious. The pattern has covered every possible question I can have. Which book do I start with? Ask help from a mentor like a professor or pick a book that covers a broad spectrum of the topic I want. Which book next? If I want something in the same area, I can go deeper. For example, after software development, now maybe I can focus on web development or mobile application development. If I want to learn a new language, I can google the most in demand computer language and chose from there. Sometimes I can find our next book within the bibliography of the current book I am reading. If I want to expand my horizon and read something outside of computer science; I can publish my list online and ask my peers and more experienced community members to guide me.

The pattern also recognizes that sometimes in order to keep the list updated, the order of the books will keep changing. Moreover, sometimes due to priority changes or simply advances in technology, some books will keep dropping down in the suggested column and we might never get an opportunity to read them.

Where I disagree:

Nowhere, unless there is a pattern out there that can control a person’s mind and force them into start reading.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Share What You Learn

So this is a pattern that I’m entirely unfamiliar with, as I don’t consider my understanding of a majority of the material sufficient enough to be able to reliably pass it on to another person. However, the pattern immediately addresses this by noting that every little nugget of knowledge can be valuable to someone who might be unfamiliar with it. And as a result, that bit of understanding can thereafter be passed on again, and cascade from the little help that I might have given a fellow programmer. In some ways, it may even be more beneficial to learn tidbits from a peer, as the author mentions that we would be speaking the same language in terms of familiarity. 

While the pattern references the fact that people may not appreciate what you share, I wholeheartedly agree that properly teaching somebody else will solidify the techniques in one’s own mind. If someone is struggling but isn’t willing to hear what you have to offer, they need to improve over several areas in their own right. 

I find it fascinating that the author mentions to be cautious about what you share, as you might be stepping on the toes of a higher up, and unintentionally disclose something that was valuable to an employer. It’s certainly something I’ve never considered before and will take into account going into the future. I’m also glad he mentions the fact that sharing a lesson could be interpreted as conceited or aloof, because from personal experience I’ve lost respect for people like this faster than a Hello World program executes. All in all my takeaway is to temper what you say and read the room when deciding when or when not to share; quite the valuable lesson. 

In the Action portion, I don’t necessarily agree with the recommendations made. Of course there’s no problem with writing blog posts and sharing workshops, but I regard the most important lesson to be to think about how you would engage with someone treating you the same way, if you were approached by them in the same situation. Teach in engaging ways and foster curiosity in your peers, but only if they are willing to accept your olive branch. It’s ultimately a waste of time to preach at someone who isn’t really listening, and worse, judging you for engaging with them.   

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns – Breakable Toys

My biggest takeaway from this is to simply build more things that don’t work, so later on I have the knowledge to make things that do actually work. The quote of the three ball juggler not attempting to push the limit to five balls during a performance is an analogy that really spoke to me in that regard. 

I think the idea of building a personal wiki would be a phenomenal practice for my growth, as I’m constantly forgetting general syntax or git commands that sometimes slow my production rate to a crawl. I built a game for another class that emulated the classic Flappy Bird from a few years ago, and getting that to function would have taken my ages and ages without the help from my groupmates. But reflecting on the experience now, the amount of times we broke that game and the thrill of being able to actually PLAY what I made was something I’d never experienced. Nor with any other art, as I’ve never been one to share any of the sparse create projects I seldom try to come up with. Reading this pattern has kind of put that creation process in a better context for me now, and I hope I retain that going forward as I expand my portfolio to apply for career positions in the future. 

I also like the idea that I own these broken things, but that they will stay with me wherever I go. Just because I can’t make something work at first, doesn’t mean years or months down the road I can easily slap on some extra padding and see how much I’ve grown as a creator. 

Reading on, the Action section really sums up everything that I just reflected on. Especially the wiki idea, which will be the first thing that I try to implement. I know I’ve kind of been harping on very similar patterns, as referenced in the See Also section, but I think this is the biggest area of improvement that I need to work on. For my last post I’ll be sure to expand into a more diverse pattern just to expand the repertoire, but I think it was important for me to recognize the importance of my harping on these specific topics.

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

A Different Road

This Apprenticeship pattern, “A Different Road” is about admitting to yourself if software craftmanship isn’t the career path you want anymore. I think that this is a very important lesson to be learned, because it is much more harmful to yourself, and others that you work with in your field if you stick through doing something you don’t like than if you either take some time away or change career paths entirely. By doing something you don’t like as a career, you are doing a disservice to yourself and others, because you most likely aren’t doing the best as a software developer as you could if you don’t like it, and others may notice that you don’t like it and that you aren’t doing the quality of work that you used to, or that it is less than acceptable.

I think that instead of changing career paths immediately if you aren’t enjoying it anymore, maybe a good idea would be to take some time away, and then return to it later and assess whether you still aren’t enjoying it or not. The reason for this would be to see if you just have burnout from doing it for a while, and then maybe the time away would fix that burnout. You could have burnout for a number of reasons, but maybe taking some time away would fix it by helping you clear your head, and then if you’re still having burnout then it might be time to seriously consider changing careers.

Ultimately, I think it’s best to not force yourself into a career you don’t enjoy doing, and that goes for any career path, not just software development. Not enjoying what you’re doing everyday means that you’re likely doing it worse than you would if you were enjoying it and will inevitably lead to unhappiness. In my opinion, it is much better to do something that you enjoy doing and something you’re passionate about than something that has better pay. Additionally, there will always be other opportunities down the line, meaning a temporary career shift doesn’t have to be permanent, and you can either continue doing what you are, or return to the old job if you’ve discovered that’s what you like best.

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

Expose Your Ignorance

This Apprenticeship pattern, “Expose Your Ignorance,” is about admitting to others as well as to yourself the gaps in your knowledge. You must admit to yourself the gaps in your knowledge before you can admit it to others and begin to ask meaningful questions to expand your knowledge. I think this is really important to know because if you are unwilling to admit that you don’t know some stuff, then you will be unable to learn it, and furthermore unable to get help from others who possibly know more about the topic. Only by admitting that you have more to learn can you open yourself up to attaining more information, which will help you in the long run.

I think that this is especially important in the software development field, where there are constantly new technologies and tools to learn, and new information about emerging systems that you must learn to keep up with the ever expanding field on software development. If you don’t keep up by learning new things, and thereby exposing your ignorance, then you will quickly fall behind, and may be susceptible to being replaced at your job, or incapable of performing the tasks necessary to fulfill your goals.

I also think that this is applicable to many different fields, not just software craftmanship, where there are always new things to learn, and you must keep up to date with the latest information in order to do your job. One such example would be a doctor, where there is always new medical information coming out, and not knowing about it could be potentially harmful. Any person in a field such as this must be okay with admitting that they don’t know something, instead of pretending like they do and not learning new, important information. Admitting that you don’t know something, and exposing your ignorance, not only makes you seem humble to yourself as well as others, but it also helps others to assess what you do or don’t know so that they are able to help you in areas where you may need it, and you are able to help yourself in this way and by learning it on your own.

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

Record What You Learn

Summary:

‘Record what you learn’ pattern comes from the chapter ‘Perpetual learning’ and Perpetual meaning ‘occurring repeatedly’ the pattern sits well. ‘Record What you learn’ Pattern is a perfect read after ‘Breakable Toys’ and ‘Practice, Practice, Practice…’ because the pattern exposes one the biggest flaw in our learning which is that sometimes even after learning the same lesson repeatedly “They never seem to stick.” The solution pattern provides is for us to record what we learn. Make timely organized notes in form of journals and wikis. Moreover, the notes could be public or private; public for the purposes to share your knowledge and discoveries and private where you can act as your own oversight and pinpoint all your faults with brutal honesty.

Why this pattern?

For me, ‘Record What You Learn’ is a perfect sequel to ‘Practice, Practice, Practice…’. I have written many programs in Java, but from time to time I’ll forget something specific like casting the input variables, using extends or implements in OOP. The point is this has happened to me various times until I started making personalized notes for myself instead of depending on textbooks and class notes. I started writing things down the way I understood them; using the color-coding system to my advantage, I highlighted parts that were important to remember, parts with specific steps and parts where I needed help. Classification of information not only proved to be effective for quick reviews and revise but also helped in conveying myself to people who can help me in precisely where I needed help.

Where is disagree:

Most of the time while building my personalized notes there was a lot of overlap. Classification of information was effective but the process of classifying the information itself was tedious and chaotic. As I kept learning new things, adding notes, and modifying notes became a very complicated process. Absence of space led to arrows being from the top of the page to the bottom. References were made from page 31 to page 45 which led to a whole new level of mess. Switching to taking notes on the PC solved a lot of issues from being on paper but created a lot of new ones. One issue was the mechanics of completing a task. It is much easier switching between a pen to a highlighter than a keyboard to mouse, and further selecting area to highlight.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Blog 8: Practice, Practice, Practice

The context given here is that You want to get better at the things you do and you want to develop concrete skills in new areas. The problem is now that the performance of your daily programming activities does not give you room to learn by making mistakes. It’s as if you’re always on stage. The solution offered is to take the time to practice your craft without interruptions, in an environment where you can feel comfortable making mistakes.

Practice is important because it will get you to where you need to be. We talked about reading and going back to the classics as a way of getting you to master your craft but reading without practicing the acquired knowledge won’t really help. That’s why we believe efficient and deliberate practice methods not only help you learn faster but also help keep you motivated. Over time, this chain of exercises would hone your strengths and correct your weaknesses.

The book emphasizes that short feedback loops need to be incorporated into your practice sessions. While practice is good in theory, if you’re not getting periodic feedback, you’re probably developing bad habits. Over time, the need for constant feedback lessens as you grow as a craftsman, and is gradually replaced by your duty to take on the role of a senior apprentice, modeling good habits by practicing with less experienced developers.

I was very surprised by the following sentence: “Your grandmother may have told you that practice makes perfect. She was wrong. In fact, practice makes permanent. So be careful what you practice, and constantly evaluate it to ensure you haven’t gone stale. Choosing the right thing to practice every day is a skill almost as important as the act of repeated practice.”

The lines above shows that we could easily get comfortable and stop making concrete progress. Practicing is good but it has to be diverse to allow the growth to happen. The point is not to hone your memory, but to discover the nuances in even the simplest skilled activity. An easy to implement it could be as simple as finding an exercise in one of your old books and tweak it a little bit to make sure that it’s just a little harder than one you know you can easily solve.

From the blog CS@Worcester – Delice's blog by Delice Ndaie and used with permission of the author. All other rights reserved by the author.

Blog 7: Read Constantly

The context of this pattern is that you are being enthusiastic about your passion to the points where it has open doors for you. The problem is such that there seems to be an endless stream of deeper and more fundamental concepts that are eluding you, despite the proficiency that you already have. The solution offered is to focus the thirst for learning on consuming as much of the written word as possible. Emphasize books over blogs as you construct your reading list.

The book emphasizes that reading the occasional research paper will stretch your mind and keep you in touch with the cutting edge of computer science, and also offers a source of challenging new ideas. Trying to implement these ideas will expand your toolbox with new algorithms, data structures, and design patterns many years before they reach the mainstream. An Important fact to remember is that Successful apprentices tend to focus on “long-lived books” and use the Web or experimentation to learn how the information has evolved and that’s why we should focus on going back to the classics. That being said, one danger of focusing on the classics is taking it too far and abandoning the more pragmatic knowledge and information that enables you to improve your day-to-day craftsmanship. Be sure to intermingle classics with modern, pragmatic books and/or articles in your reading list.

I really resonated with this because reading books hasn’t always been fun for me. Thankfully, the eBook and audio version of things have made it easier. I also like that they ended the pattern by the following: First, the trick is to keep up the momentum. After you’ve finished this book, decide now what your next book will be and make sure to buy or borrow it so that when you finish this book, you can switch immediately to the next one. Second, you should also try to keep a slim book with you at all times. This will let you use the little bits of dead time throughout each day (such as train journeys or waiting in queues) to learn. Third, Find the oldest book in your developer’s book collection and read that one first.

From the blog CS@Worcester – Delice's blog by Delice Ndaie and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Chapter 5

Breakable Toys

Success is often a tool used to measure how effective you are as a programmer, but this isn’t quite true. Failure is often referred to as the great teacher, as learning from mistakes that you make is great for improving yourself. The idea behind this is that if everything you make is bound to succeed every time then the process behind it might not haven hard. Things that don’t challenge you are not going to fail for you, but at the same time you are not going to learn anything from it.

This pattern is to take something, try to build it, and learn from your failure. You can be skilled and incredibly proficient in your strong suits but if you are not failing as you proceed you might not be challenging yourself. You might stagnate in your skill, and while you can be incredibly good at it, you still are not learning anything that is challenging you.

This particular pattern I agree with. Learning through adversity is often a great motivator. For some, time is an incredible motivator and through procrastination you have a literal time limit challenging you. For some, something new is an incredible motivator as it’s something utterly foreign and waiting to be explored. You should try something new to learn how your own skills are developing. Failure at first can deter you but taking this approach will teach you how failure will motivate you. You couldn’t succeed, but it doesn’t mean you cannot. You’ll find yourself thinking endlessly on that failure and seeing how others have succeeded where you failed will motivate you to think it has to be done. After all someone else has done it or likely created something like it. Take on a new library, build something that you never have before and let it break apart in your hands. Take the pieces and try building it again. In a sense you are letting yourself be broken by your broken project. Just challenging yourself will not be enough you have to learn from failure and learn how to fail. This pattern honestly should be called Breakable Self, as the learning portion isn’t the failed build, but rather using that failure to break a common mindset to succeed where you once failed.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.