Chapter 11 covers the topic of interview anti-patterns. Basically it covers what to avoid as someone giving an interview to attract true software craftsman.  The author first suggests to avoid intimidating the candidate as well as to avoid trying to seem smarter           than them. An interviewer should be humble and treat the interview as a professional and technical conversation. Relying on brainteasers and questions irrelevant to the open position should also be avoided as it doesn’t pertain to how well they’d do the job at hand. The author also highlights other suggestions such not blocking the internet, not to code on a whiteboard, and not to conduct phone interviews. His advice is to make the interview as relevant as possible to the job; use real tools and write code on a computer. Software craftsmen are also interviewing the company and as the author says will reject offers from bad companies.

After reading chapter 11 there is a lot that I agree with but some things that I do not. First I strongly agree with avoiding brainteasers or situations that make it seem like you are trying to outsmart the candidate. It’s uncomfortable and if the interview seems stressful, one can only assume how bad the actual job would be. I also strongly agree with not blocking the internet. If someone is stuck on a question, they should be given the chance to find the answer however they see fit. As a software developer you will always have tools and resources to help you with whatever problems you come across. One thing I slightly disagree with is not writing code on a whiteboard. I think this is perfectly legitimate for base knowledge coding problems or algorithms that will pertain to the job especially for a junior level job. For more senior developers, their work and portfolio should be able to speak for themselves. I also disagree with not conducting phone interviews. The phone interview doesn’t need to be extremely technical but it’s good to make sure the company and candidate are on the same page. If this short conversation can filter people out then I see that as valuable time saved. Perhaps someone thought the job encompassed other responsibilities and were disappointed upon coming in for the interview. There’s no need to allow those kinds of situations to occur. Lastly I believe that companies spend a lot of time in creating their hiring process. Just because they may proceed through their selection process different would not make me reject an offer. Above all I look for a job I’d be excited to go to every day and people I can relate to. The selection process can be very generic for larger companies and won’t always reflect the open position. It’s up to the candidate to dig deeper and see if it’s something they truly want.

Chapter 12 covers the topic of the cost of low morale. The author touches upon how a team with low morale can bring an entire company down and just how costly it can be. The first contributor to low morale mentioned by the author is what he calls the “agile hangover.” The agile transformation that swept many companies did very little to improve developer’s technical skills. They had a new process but were still developing the old way. If anything this hurt team’s motivation even more. Another contributing factor is the employment of 9-5 developers. These are developers who don’t actually care about their job and are just there to collect a paycheck. They have no sense of urgency and do not care if they show zero results. While some people simply can’t be motivated, hiring a few craftsmen to a team can definitely turn things around according to the author. They can help fix technical issues, bring new innovations, and get a team excited again. Craftsmen can get a team to enjoy their work more which drives better results. Developers who enjoy their job will care and improve their skills.

After reading chapter 12 I agree with the ideas presented by the author. I do think he makes the situation seem a little easier than it truly is though. Not many companies can afford to hire a few craftsmen developers on to a team for motivation. I also think it would be tough even for a few craftsmen to get an entire team excited about their job. If a team and its members have dropped that low in caring then some employees probably just need to be let go. It could also be management or general company culture that has caused a development team to be so poorly motivated. Hiring some craftsmen will not fix a companywide issue.  Also if a true craftsman were to listen to the author’s hiring advice, they would most likely not take a job with a team that lacked morale. I agree that low morale can cost a company a fortune but I think the issue goes deeper than the advice offered by the author.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

Chapter 9 covers the topic of developer recruitment. The author makes an immediate claim that job board type sites with the traditional job description are a bad way to hire developers. Many job postings list an abundant amount of technologies that aren’t even required to do the specified job. This immediately filters out some really good candidates. Listing years of experience can also filter out good candidates because years is not necessarily a measurement of knowledge. The author goes on to say that many larger companies continue to get developers similar to their “bad” ones because they are relying on their poor recruitment process. Getting rid of generic job descriptions and avoiding the mistakes mentioned, gives access to a wider range of potential craftsmen. This can also remove any obscurity the recruiters have with not understanding the true technical aspects of the job and prevent keyword matching. Another piece of advice given is that companies should avoid financial compensation for employee referrals. It creates wrong motivation and incentive to recommend a potential employee. Working with talented people who improve the quality of the work environment should be compensation enough. It is suggested that companies should always be proactively recruiting. Getting involved in tech communities and user groups is a good and cheap way to gain exposure to potential talent. By building a pool of candidates for future employment, the hiring process can move much quicker. Lastly, the author suggests that you look for passion above all else when selecting a new developer. Someone who blogs, contributes to open source, or attends conferences will likely see the employment opportunity as more than just a job. In summary, if you are currently dealing with “bad developers” look to change the recruitment process to hire the people you really need.

After reading chapter 9 I found a lot of the author’s suggestions and advice to be helpful for my future. While I agree with his points, many companies still post job descriptions like the ones he called out. For people who are unemployed it’s not always easy to find the perfect place to work never mind go through a selection process for a company that isn’t even hiring right away. I strongly agree with the author’s comments about not listing years of experience on a job description. It can filter out people who are newer but more current with a technology and keep people who have done the same exact thing for “X” amount of years. One thing I have noticed looking for entry level software jobs is that companies post long lists of specific technologies for required skills. I think it’s more important that a candidate demonstrates the ability to learn new things. Having a coding assignment as part of the selection process can allow candidates to show their adaptiveness to new technologies as well as give a current sample of work. I have also seen job postings for entry level or junior developer positions that require a lot of experience or many technologies. I can’t imagine postings like this can get very many applications as they are not practical. While I agree with the ideas in this chapter, the hiring process in the United States is still far from adopting them as the new norm.

Chapter 10 covers the topic of interviewing from both the company and candidate side. The author gives a helpful reminder that an interview is not someone begging for a job. It is a business negotiation with the goal of creating a good partnership. As the demand for software developers is at an all-time high, candidates do not need to settle for anything less than a good partnership. From the perspective of the company giving an interview the author makes several points. In general it is best to focus on the candidate’s enthusiasm, projects, and achievements and not necessarily hard skills like a particular technology. He also says to favor those who ask questions showing genuine interest in the company and their role. Lastly it’s important to not only give a clear outline of the open position but to make sure it matches what the candidate is looking for.  The author also gives advice from the perspective of the candidate. He suggests to take the time in the interview to analyze everything about the situation. Learn as much as possible about the work environment, hiring process, and actual role you’d be filling. A good interview should also have some key elements to it. For one, the interview should feel more conversational and not like a scripted test. You can’t truly show or find passion and talent with questions requiring yes and no. It is also suggested that some form of coding be part of the hiring process. This could be a pair programming session or a pre-interview coding assignment for filtering. A software developer should also be a part of the interview process at some point. Developers interviewing developers is beneficial for everyone. In conclusion a good interview will form a productive partnership that both sides are enthusiastic about.

After reading chapter 10 I strongly agree with the interview advice given by the author. In regards to asking questions in an interview, I can’t imagine I’d be very interested in a role that I didn’t want to know anything about. I also think it’s important to remember how much time you truly spend at work. Most of your time is spent on the job so I think the most important point is that you can see yourself being happy going to work every day. While I think it’s important to analyze the logistics of the interview, many times people can be very nervous going into an interview which can hinder the execution of their interview game plan. I believe a good interviewer will get the candidate comfortable in a conversation before getting to the important parts. Lastly, as a soon to be developer I think it’s important to remember the abundance of jobs there are in the field. I can’t settle for something that I won’t be truly excited about. It makes for a bad partnership and violates all the advice given by the author as a software craftsman.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

In Sprint 5 we were finally able to make meaningful code changes on our new issue (APTS-296). We basically focused the entire team on the issue because the semester is quickly coming to a close and we want to have a pull request accepted before our last sprint finishes. This issue took a while to figure out because the code we needed to modify was in the node_modules directory and we were only focusing on the src directory. Once we broadened our search to node modules we able to successfully modify the code and run it on the AMPATH test server. I think by focusing everyone on our issue it allowed us to make sure we were able to come up with a solution. Luckily during this sprint nobody has had server issues and we have been able to pull changes from upstream with no major problems. Looking at the next sprint our main focus will be to get a pull request submitted and accepted. To do this we will need to set up Travis CI on our team’s GitHub repository and squash all commits to one so that AMPATH accepts our changes. Overall we had a productive sprint and we will focus all of our effort on the pull request in our last sprint.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

Chapter 7 covers the topic of technical practices. The author explains that Agile methodologies help build the right thing but craftsmanship focuses on technical practices to the build the thing right. These practices are referred to as Extreme Programming and have been considered part of Agile since 2001. The problem is that many companies did not adopt Agile’s technical practices for a number of reasons including they weren’t shown the business value of them. The practices mentioned by the author are as follows:

Automated Testing                                          Test First

Test Driven Development                             Continuous Integration

Pair Programming                                         Refactoring

All of these practices provide business value in the form of shorter feedback loops, cleaner code, improved system knowledge, or increased maintainability. The author goes on to say that all developers including managers should be held accountable for the practices they adopt and even more the ones they choose not to. Lastly the author reminds us the importance of pragmatism in being a software craftsman. Developers should always look for ways to doing their job better. It’s the developer’s job to adopt the right practices which provide the best business value and provide maximum customer satisfaction.

After reading chapter 7 there are definitely some good takeaways for my future development. Primarily I think it’s important to remember that it’s important to continuously look for ways to add value to your environment. While there might be a learning curve in adopting new practices, focusing on the business value in the future should suppress any doubts. While I don’t think every project needs to adopt every practice of Extreme Programming, I do think there is at least one practice that every project can and should adopt. At this point in my software development knowledge I would be hesitant to join a team in the future that was not practicing some sort of automation testing or TDD. It has been brought up so frequently by major role models in the programming world that I don’t think I could settle for anything less.

Chapter 8 covers the topic of the long road of a career to mastery. The author explains that it’s important to take control of your career and break it down into small iterations like you would a program. After each iteration, re-revaluate short term and long term goals and make sure your career is in alignment. If you’re not sure about your future then it’s time to create new opportunities to open doors for yourself. These can include attending tech events, blogging, or presenting at a conference. One thing to keep in mind is that your career is an investment. Maintaining and improving technical knowledge will always ensure a software craftsman is never too far from a job opportunity with the stability and security they need. The author goes on to say that aside from money there are three things which should motivate a developer in their career: autonomy, mastery, and purpose. He also warns the reader not to get caught up too much in a career inside a company. This can cause a shift away from personal goals and towards just getting the next promotion. He mentions that this is a common path to having under qualified and outdated managers. In conclusion a developer must understand where they want to be in their career and focus on reaching their own goals over a company.

After reading chapter 8, I think there is some really good advice to remember for my future career. I really liked his statement that knowledge is forever. I truly believe that if you maintain your skills and knowledge you will always be prepared for what life may throw at you. I do believe this chapter was aimed more for developers who have at least several years of experience. As someone who is just entering the field, I can’t be too stringent on the specifics of my first job. While I would not take a job doing something I absolutely hate, I think that you need to make a little more sacrifice in the beginning so that you can dictate the path of your career as you gain experience. Lastly I fully agree with valuing a personal career over any career within a company. If at any time it seems like you need to sacrifice your future goals to stay with a company then it is probably time to leave. This chapter was a good reminder that we are all responsible for our own path.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

Chapter 5 covers the topics of trying to be a hero and having goodwill as a software developer. The author highlights many of his previous jobs where he was extremely overworked, forced to meet unrealistic deadlines, and worked on large scale projects without any client interaction. These are all definite no’s for a software craftsman. The first lesson is learning to say no. Over working creates bad code which is bad for developers, managers, and clients. A manager can’t be allowed to dictate impossible tasks. Development teams need to stand their ground on what can realistically be done with a constant communication flow to managers and clients. When a developer has to say no, they must provide alternatives or suggestions to the problem. Developers must always be clear about what can get done and any concerns should be addressed as soon as they arise. Keeping transparency with managers and clients allows everyone to work as a team to deliver the best product by a deadline. Also, managers should work as part of the team, facilitating workflow and protecting their developers from external pressure.

After reading this chapter I would definitely have to give the author credit for sticking it out as long as he did at some of his past jobs. I can’t imagine only a few hours of sleep in a car and then back to coding especially with no overtime pay. That is clearly abuse of power by the employer and should never be allowed anywhere. One point the author mentioned that I liked was if you deliver every time you say yes and commit to something, saying no will carry weight to it. I also agree with giving options and alternatives when saying no. A flat no provides no explanation or workaround and isn’t a sufficient answer. Basically from this chapter I will take away the points to not get overworked and always stay transparent with the workflow to both managers and clients.

Chapter 6 covers the topic of working software. The author reminds us the Manifesto for craftsmanship values working software over comprehensive documentation. He then makes the argument that programming is like gardening and that code must be maintained. If code is left to rot, implementing features and changes becomes a bigger task as time goes on. The author mentions that this rotting code is usually the product of developers self-imposing time constraints and pressure on themselves to accomplish tasks quickly. One way to avoid the rotting of code is to practice Test Driven Development from the start and automating testing. That way tests are always written for new code and they can be easily run on top of the old tests. He also mentions how many developers tend to shy away from legacy code because of the frustrations it brings. Instead of focusing on the headache legacy code presents, it’s advised to pick apart small bits and improve them, writing tests along the way. By piecing small bits of legacy code into an upgraded format, huge improvements can be made over time. Lastly, the author makes the point that the cleaner software is kept, the greater lifespan of an application and the greater return for the client which is always the end goal.

After reading this chapter I think there are some good points to take away. First I liked the author’s approach to legacy code. Rather than complain and avoid it, take it as a challenge to improve the code and implement new technologies and tools. While I would still like to work on a project relatively young in development I will keep this positive outlook of legacy code bases in mind. Secondly, I think it’s clear by now that TDD and test automation are best practices in software development and are the way of the future. They have shown up in almost every book covered at this point as well as emphasized by Robert Martin. In summary, my biggest takeaway is to remember to always maintain and improve my code as an ongoing process and take the time to do it right.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

In Sprint 4 we finally got our first issue assigned. Unfortunately, our first issue (NGPOC-183) was rather difficult. It took us several days to try and understand how to tackle it and we ended up not being able replicate the problem on the test server. We had posted questions on the issue in JIRA and reached out to the developers on Slack but were not able to get any clarification or guidance. Although this issue has been a dead end so far I did get gain some knowledge in the code base and have better understanding with how the location feature works in the AMPATH dashboard. Right before break our group decided to take on a new issue (APTS-296) but we have not made much progress with it yet. Aside from our issues in JIRA pulling changes from the AMPATH repo as a remote upstream always seems to create a lot of conflicts and problems connecting to the test server. It hasn’t been anything we haven’t been able to work through but does slow progress down. We find it better to pull in changes frequently to make sure we are up to date and our changes will cause as little conflict as possible if we can get to a pull request. Looking back at the last sprint we did what we could for our first issue but the lack of further guidance slowed us down and kept us from any measurable progress. Looking forward we hope to make considerable progress on our new issue and move towards our first pull request. As of right now the team is still working well together and we aren’t going to adjust our velocity for the next sprint.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

Chapter 3 covers the topic of what exactly software craftsmanship is. The author generalizes it by stating its putting responsibility, professionalism, pragmatism, and pride into software development. He then goes on a long walk through of how software craftsmanship came to be and the history behind it. Basically software craftsmanship has been around since 1999 however it never really gained traction until about 2009 when the Manifesto was published online. The Software Craftsman Manifesto outlines four main values of a developer: 1) Not only working software, but also well-crafted software. 2) Not only responding to change, but also steadily adding value. 3) Not only individuals and interactions, but also a community of professionals. 4) Not only customer collaboration, but also productive partnerships. The author concludes with the main idea that software craftsmanship is a lifestyle and mindset of professionalism in software development and always striving to provide the best service to clients.

After reading chapter 3 I thought there were some really good points but I did think the history was a little drawn out for the reader. I agree with the manifesto the author laid out however everything he mentioned seemed to be common sense. It is also something that must be embraced by the entire business for it to be effective. While one developer could be a craftsman, it takes everyone to follow the manifesto for it to truly work and give the client the best experience possible. My favorite idea from this chapter was the ‘craftsman swap’ where developers from different companies would trade places and act as if they were a developer at another company for a week. This is a great way for teams to get an idea of what they could do better and sheds some light on how other companies are operating. Both teams benefit and can adopt the best practices from the combination of two teams. I can however see where competing companies may not want to have their competition directly working with their team to gain any kind of competitive edge. Overall, I think the Manifesto for craftsmanship holds good points any developer should be following and sets a higher standard for developers everywhere.

Chapter 4 covers the topic of attitude being a software craftsman. The author makes a point to make it clear that we as individuals are responsible for our own careers and continued learning. While it’s nice to work for employers who invest in their employees we are ultimately responsible for keeping ourselves trained and up to date. He goes on to talk about all the different ways we can keep up on our training so that we are always learning. First he mentions reading material in the form of books, blogs, or technical websites. The author does mention even beginner developers should keep a blog to document and track their progress. Next he talks about ways to practice. When practicing a problem it’s important to focus on how the problem is actually being solved and not just writing code that works. Katas which are short coding exercises or doing personal pet projects are also some suggested ways to get good practice in. Lastly the author touches upon time management. Many times we tell ourselves we are too busy but he insists to make time. We can do this by limiting habits like TV watching or social media use. He does make a point that there needs to be a good work life balance but to own your own career you must manage time wisely and keep your skills sharp outside of normal working hours.

After reading chapter 4 I noticed a lot of commonalities mentioned from Robert Martin’s Clean Coder. I strongly believe it is an individual responsibility to continue software learning at any career stage. Out of the ways mentioned I find myself following social media and blogs the most. With the speed that tools and technologies come out, blogs tend to have good early information and usually tutorials to help you learn. One thing I’m not sure I fully agree with is the Pomodoro Technique. While I think it may be useful for someone who’s off track, setting timers and keeping such a rigid schedule does not seem sustainable. Personally I know I would keep checking the time remaining which would hinder my focus. In conclusion my career will surely benefit from personal learning and proper time management skills.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

Chapter 1 covers the topic of software development in the 21^st century. Basically the author is introducing the overall theme of the book in that today’s developers are expected to be software craftsman. Just being able to write code isn’t good enough, a developer needs to have the ability to contribute to the business in as many ways as possible. The author also points out what seems to be a flaw that seniority among developers is earned by years of experience instead of knowledge. He argues that developer’s experience can be so different across technologies and industries that just years of experience should not indicate seniority. In conclusion the author is preparing the reader to learn how to become a software craftsman like he mentions.

After reading chapter 1 there’s not too much information yet but I think the author made a couple good points. The first one being that he basically demoted himself from architect to developer for the simple goal of being happier. I think it’s important to remember that in order to be successful you need to be happy above all else. I don’t think maintaining a job you are completely dissatisfied with is sustainable. I also agree with the author’s thoughts on seniority. While years of experience definitely holds value, someone with proficient knowledge of a subject shouldn’t be thought of as junior just because they haven’t developed for as many years.

Chapter 2 covers the topic of Agile development. The author gives a general idea and history of the methodology. Basically Agile was created by the most influential developers in the early 2000’s to address both process and technical oriented disciplines. These disciplines would ensure developers built the right thing and built that thing right by getting the most feedback as possible through quick and short iterative work cycles. Agile completely changed the development world and gave control to small teams who played all the roles of software development following the 12 principles of the Agile Manifesto. While the Agile takeover massively improved communication in business, it ultimately led to the Agile hangover as the author calls it. Companies were using Agile only as a process improvement and maintained their sub-par technical disciplines. Before long, companies who had adopted Agile development were back to their old ways and not seeing the results they expected. The author blames this on the companies only committing to partial transformations and neglecting to improve their technical disciplines. The author concludes saying that software craftsmanship and the Agile methodology can work together for best practice. While Agile will improve upon the development process, software craftsmanship will promote better technical practice and doing more for the client.

After reading chapter 2, my thoughts of Scrum have been reconfirmed. As one of the most popular Agile implementations, Scrum has taught me the importance of constant feedback and changing demands to work in the most efficient way possible. I can definitely see how the Agile hangover was destined to happen. Focusing on the development process was a great idea but lower level disciplines of writing good code should have been enforced before if not alongside the adopting of Agile techniques. This really shows that no method or technique can outweigh bad code or lack of technical discipline. Having seen the effects of only focusing on improving processes I do wonder if Agile coaches and professional training seminars are better equipped to address the importance of technical improvement alongside Agile development for optimum results. In summary Agile development is a great technique for a development team but must be accompanied by correct technical practice through software craftsmanship.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

In sprint 3 we got more involved with writing code for AMPATH. Basically, each group member tried to write the authentication module from scratch. I was able to write about 50% on my own but needed to do a lot of verification with the working module. This was about the level of knowledge for the whole group. Our definition of done for this task was to just do as much as we could on our own and use the working module for assistance as needed. We decided on this because we need to be moving forward with more meaningful tasks. Also during this sprint, the AMPATH developers added a new test server for us to connect to for running an AMPATH instance. This was very helpful because we were constantly having issues with the openMRS standalone and its server. The whole group was able to connect to the new test server pretty quickly and it has not given us any trouble since. The last major task for this sprint was creating our account and getting logged in to AMPATH’s JIRA system. This system is used for issue tracking and with an account we can assign ourselves to specific issues. Our group was assigned one issue so far but we weren’t able to nor did we plan to get to it this sprint. Overall our group had a successful third sprint. We were able to get the tasks we committed to done and our knowledge of the AMPATH code base has been getting stronger. The only thing our group needs to improve on is our daily scrums in Slack. We have great communication in class and everyone is doing their tasks but we are struggling to communicate our progress outside of class time. I believe in the next sprint communication will be easier because we will all be working on the same issue. Up until now our tasks have been individual so working together has only been necessary if we get stuck on something. In conclusion another strong sprint for TeamLoading.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.

Chapter 13 covers the topic of teams and projects. The author talks about two different approaches with projects. The first approach is that a team is selected for a specific project. Usually these people who are selected are also working on several other projects and they are not familiar with each other’s work habits. This type of team usually works slow and is not the most effective in completing a project. The second approach is to select a team that highlights all the necessary skills and keep them together for as many projects as possible. Over time this team will start to “gel” as the author calls it and will become extremely efficient at working together. The only down side that is mentioned is relative to the project owner. The project owner lacks some security in relying on their team’s resources because the team can make a short term allocation of all their effort to another project in an emergency. In conclusion the main lesson here is to form a good team and move through projects together, getting better after each one.

After reading chapter 13 I definitely think the approach of forming a team and keeping them together makes the most sense. By working with the same individuals you can build relationships and form a reliable team that can get projects completed. Unfortunately, as a junior developer I will have little influence on how a company or department approaches their projects. I will however keep this team approach in mind for project decisions when I am more senior. I think it’s important to note that sometimes a team may need to change some of the members intentionally. Maybe one person isn’t working well with others or maybe you need to add a member with a special skill. Keeping a team together is important but I think there should be an overall assessment after each project to make sure improvements are being made when possible.

Chapter 14 covers the topics of mentoring, apprenticeship, and craftsmanship. The author first talks about the different forms mentoring can take. It could be a programming manual, observing a teacher, or really anything that pushes you in the direction of improving your knowledge. He then makes a point that in programming recent graduates often get thrown on to teams without a true training phase like most other professions. He talks about a hypothetical hierarchy of master programmers, journeyman, and apprentices. As a programmer gains experience they shed some of their technical supervision and gain responsibilities including mentoring those junior to them. This chain reaction of elders teaching the young is what leads to programmers becoming true craftsmen and professionals. When junior programmers have good role models they become those role models over time.

After reading chapter 14 it’s clear that proper mentoring is necessary to grow into a craftsmen programmer. I don’t think the author places enough responsibility on the junior programmers though. As a young programmer it’s important to recognize the proper role model and seek mentorship from the more senior programmers who are doing things right. While mentors should reach out to the junior programmers it’s still important to take charge of your own path. Entering the software development field, I’d like to think I will have good mentors that will help guide me in the right direction as I move through my career. If I find that I lack the proper mentors, I will do my best to seek out the professionals I will need to one day become a mentor for those junior to me.

From the blog CS@Worcester – Software Development Blog by dcafferky and used with permission of the author. All other rights reserved by the author.