#TheCleanCoder

[asadmukhtarr]

"The Clean Coder: A Code of Conduct for Professional Programmers" by Robert C. Martin, also known as Uncle Bob, is a seminal book that delves into the principles of professionalism in software development. It provides practical advice on how to behave, communicate, and work effectively as a software professional. Below is a user-friendly, step-by-step breakdown of the key outcomes and takeaways from the book, designed to help developers enhance their professionalism and career growth.

[nedyaj-blog]

Mentorship

In the final chapter of The Clean Coder, Uncle Bob discusses the education (or lack thereof) that we receive in programming university courses and how the burden of responsibility to guiding new software developers to maturity will fall to senior developers in the form of mentorships. He uses the example of doctors within the medical field who, after completing school, go through several years of rigorous mentorships (residency) and being supervised before applying for board certification. Given that software runs much of the world today, some of which can be life threatening if done improperly, why aren't software developers required to go under a period of training and supervised practice as well?

According to Uncle Bob, an ideal software apprenticeship will be structured as follows, starting from the top level:

Masters

Programmers who have been in the industry for typically 10+ years and have worked with several different kinds of systems, languages, and operating systems. They know how to manage projects and lead teams, and may have a management position while still remaining technical through studying, practicing, doing, and teaching.

Journeymen

Trained, competent programmers who have an average of about five years of industry experience and are knowledgable about current technology. They typically aren't well versed with many different kinds of systems and languages, but are working towards learning more. They are supervised by masters or senior journeymen and their code is often closely supervised and scrutinized. As they gain experience, the level of autonomy grows.

Apprentices/Interns

University graduates start out as interns or apprentices. They are mentored by journeymen and are very closely supervised. Journeymen assign readings, exercises, and practices to apprentices and they review their progress and provide feedback. Disciplines are learned and reinforced and the foundations of values are created. Apprentices should last about a year and if the apprentice has successfully completed the apprenticeship and the masters approve of his/her accomplishments, the apprentice becomes a journeyman.

Uncle Bob makes the assertion that while school teaches us the theory of computer programming, it does not teach the discipline, practice, and skill of being a software craftsman. I agree wholeheartedly with his statement. While I didn't exactly pursue a CS degree (I got a Computer Engineering degree), I was still required to take several programming courses. Within those courses, I never learned any of the disciplines and practices that I have taught myself after graduating and in the (less than) two weeks of my apprenticeship. Sure I learned object-oriented programming, data structures, C++, and Java to name a few things, but I was never taught values or disciplines. These courses were more like, "if it works, then you pass! if it doesn't, figure out how to make it work by any means necessary." I never learned how to write good code or how to code the right way. While it's a shame that universities don't and can't quite teach discipline and value to students, it's great that there are software apprenticeship programs that will teach young inexperienced developers how to become clean coders and put them on the path to becoming craftsmen.

[thisitgurl-blog]

Excerpts from "The Clean Coder"

Read this book earlier this year and loved it! (Is it weird to say that on a technical book?haha)

"The Clean Coder" by Robert C. Martin talks about a code of conduct on professionalism for developers. It demonstrates very clear examples on software development pitfalls by fault of the developer not adhering to professional ethics and discipline. This book is a must read for any to-be or experienced professional developers out there! You will also love Robert's style of writing because it's entertaining and told as if he was telling a story. He also shares MANY of his personal experiences in the software development industry and you'll see that he has gone through a LOT! And when I say experiences, he also shared both the good and the dirty; all of which are entertaining, informative, and inspiring! Here are some excerpts from the book that truly struck me.

"Years of experience have taught us that breaking disciplines only slows us down"

"Working while distracted creates waste"

"I remember thinking that working at 3am is what serious professionals do. How wrong I was!"

"Don't write code when you are tired. Dedication and professionalism are more about discipline than hours. Make sure that your sleep, health, and lifestyle are tuned so that you can put in eight good hours per day."

"The hours I spent away from my usual problems, while being actively stimulated by challenging and creative ideas, results in an almost irresistible pressure to create something myself."

"It is unprofessional to remain stuck when help is easily accessible."

"Why don't you fix bad code when you see it? Your first reaction upon seeing a messy function is 'This is a mess, it needs to be cleaned.' Your second reaction is 'I'm not touching it!' Why? Because you know that if you touch it you risk breaking it; and if you break it, it becomes yours."

"No professional developer should ever follow a discipline when that discipline does more harm than good."

"When the business actually sees what they specified running in a system, they realize that it wasn't what they wanted at all."

"In the end, the more precise you make your requirements, the less relevant they become as the system is implemented."

"Professional developers understand that estimates can, and should, be made based on low precision requirements, and recognize that those estimates are estimates. To reinforce this, professional developers always include error bars with their estimates so that the business understands the uncertainty."

"I once heard from Tom DeMarco say, 'Ambiguity in a requirements document represents an argument amongst the stakeholders.'"

"...acceptance tests...written by a collaboration of the stakeholders and the programmers in order to define when a requirement is done."

"Acceptance tests should always be automated. There is a place for manual testing elsewhere in the software cycle, but these kinds of tests should never be manual. The reason is simple: cost."

"The cost of automating acceptance tests is so small in comparison to the cost of executing manual test plans that it makes no economic sense to write scripts for humans to execute."

"These tests will prevent you from implementing the wrong system and will allow you to know when you are done."

"Kent Beck once told me something profound: 'Any argument that can't be settled in five minutes can't be settled by arguing.'"

That's about it. I hope you enjoyed reading the quotes. I also hope that you'll get the chance to read the book! And if you have read the book, please share some of your favorite texts or thoughts on it by leaving a comment :)

P.S. It's been almost 2 months since my last post and I still haven't posted the one regarding MOOCs. Been really busy lately with work but rest assured, I'll post it soon (hopefully). I also want to research more on this so I can provide helpful references :)

Till then!:D

[sammyrulez]

Una settimana di codekata

Entusiasmato dalla lettura di "The clean coder" e animato dalla volontà di migliorare il mio Python ho deciso di eseguire questo code-kata.

This Kata is straightforward. Implement a binary search routine in the language and technique of your choice. Tomorrow, implement it again, using a totally different technique. Do the same the next day, until you have five totally unique implementations of a binary chop. (For example, one solution might be the traditional iterative approach, one might be recursive, one might use a functional style passing array slices around, and so on).

 Piccolo premabolo: per chi non lo sapesse sono molto appassionato di arti-marziali, ho fatto Karate per diversi anni e quindi l'idea di kata e i suoi obbiettivi sono fortemente radicati in me.

Ho creato un repository su bitbucket con le varie parti del kata. Chicca iniziale c'è un unico metodo di test chiamato "chop_kata_moves" che prende come parametro un oggetto function e ci lancia sopra i test che verificano il kata stesso, come se fossero le mosse da eseguire.

Giorno 1  src

Classico approccio ricorsivo, come lo averi fatto all'esame di info1

Giorno 2 src

Approccio classico, ma iterativo. Devo dire che mi è servito per familiarizzare meglio con liste , built-in e trasformazione di tipo ( e la mancanza di essa) nelle operazioni in virgola mobile.

Giorno 3 src

Tento un approccio funzionale e iterativo, tentando di fattorizzare il più possibile e limitare l'uso di if. Utile per capire meglio la strutturazione di un algoritmo dove anche le funzioni sono oggetti e usarne correttamente i riferimenti.

Giorno 4 src

Qui inizio ad essere a corto di idee. Utilizzando la definizione stretta dell'algoritmo di binary-search non riesco a trovare una soluzione completamente diversa dalle precedenti. Analizzando per�� il significato dell'algorimo mi convinco che l'idea base è eliminare porzioni della lista rapidamente e progressivamente, circa log2(N) − 1.  Quindi me ne sono venuto fuori con questa soluzione che dovrebbe avere approssimativamente le stesse performance e mi pare abbastanza elegante nella struttura.

Giorno 5 src

Galvanizzato dal risultato precedente ho cercato di mettere tutto insieme: funzioni , OOP, iterativo e ricorsivo: e ci sono riuscito!

Conclusione: questo kata ha funzionato benissimo. Ho imparato a guardare le cose da punti di vista differenti, ma veramente differenti e mi sono sforzato di farlo in maniera pythonica. Nota a latere: il TDD funziona benissimo qualora qualcuno avesse il dubbio provi a fare questo Kata.

Chicca finale.. il report del coverage... risultato atteso in un code-kata TDD!

[nedyaj-blog]

There is No "I" in "Team"

Long gone is the notion that programmers work in dark corners by themselves while they type away on the computer. Nowadays, programmers are expected to communicate and collaborate with team members to get projects done. In The Clean Coder, Uncle Bob discusses what it means to be a team member and ways to collaborate with others.

The first responsibility of the professional programmer is to meet the needs of his or her employer.

As programmers, we should know the business side of the projects we're working on. It doesn't mean that we need to know every single thing about the business, but we should at least have a deep understanding of the business goals. This means that we'll have to work with people like managers, business analysts, testers, and other team members to truly understand why we're writing code and how the business will benefit from it. According to Uncle Bob, the worst thing a professional programmer can do is to bury himself in solitude without understanding the business. It is our job to keep the business running, and thus our responsibility to take the time to understand it.

Professional developers do not prevent others from working [on] the code.

So what does it mean to be a part of a team? Generally speaking, most of us like to work alone and that's fine. There is a time and place for working by yourself. However, when you're working in a team, you cannot put a shield around your code and refuse to let anyone else touch it. The team should own all the code. Learn from each other by working on the system together as a team. Collaborate by pair programming because as the saying goes, "Two heads are better than one." Pairing is the most efficient way to solve a problem, share knowledge with one another, and review code.

Team members should also sit around a table facing each other, and not in separate corners wearing headphones. While it may sound nice to put on some music and work on some code, you won't be contributing to the team. Work with each other so that you can talk to one another and help those who look like they're having a difficult time with a problem.

Programming is all about working with people.

It takes time to form a team, and when team members form relationships and learn all kinds of things about one another, the team begins to gel. While it may take quite some time for a team to truly mingle and become a solid unit, patience is not gone unrewarded. A well gelled team will plan things together, solve problems, and just get things done.

Professional development organizations allocate projects to existing gelled teams, they don't form teams around projects.

It's foolish to form teams around a project since it's much more difficult to build a solid team than it is to build a project. Because members of gelled teams have been working together for some time, they have a solid foundation of trust, know each others' strengths and weaknesses, and can plan accordingly to get the project done as efficiently as possible. A team that forms around a project doesn't have this advantage.

[nedyaj-blog]

The Pressure of Deadlines

In these next two chapters of The Clean Coder, Uncle Bob provides tips and techniques to meet deadlines while staying cool under pressure. Often times we set deadlines as commitments, and unfortunately not all commitments are carried out on time. This failure in keeping your promise is the source of nearly all distrust in any relationship, whether it be professional or personal. So how do we effectively come up with a deadline for our projects? Since problems can arise at any time, they can throw off deadlines to extend far longer than originally projected. To meet target dates, we really need to think of them more as estimates.

Businesses like to view estimates as commitments. Developers like to view estimates as guesses.

Professionals don't make commitments because they know there is always some level of uncertainty with every task. Because businesses need deadlines in order to plan ahead, they rely on the developers to commit to a target date. Professionals draw a clear distinction between estimates and commitments, and will only accept commitments when they are absolutely certain that the task can be carried out. Typically, this is not the case, and the professional will instead provide a trivariate analysis - an estimate of three numbers:

Optimistic Estimate - A wildly optimistic estimate, of less than 1% chance of occurrence, which can only be achieved if absolutely everything goes right.

Nominal Estimate - An estimate with the greatest chance of success.

Pessimistic Estimate - A wildly pessimistic estimate, also of less than 1% chance of occurrence, which takes everything that could possibly go wrong into consideration.

Given this set of estimates, we can find the expected duration of the task to be as follows:

E = (O + 4N + P) / 6

The standard deviation of the expected duration of the task is described below:

U = (P - O) / 6

This number is the measure of the amount of uncertainty a task entails. Using probability distribution to determine a realistic estimate is a good way of factoring in any unexpected issues that may arise during the task as this number considers both best-case and worse-case scenarios. Professionals are very careful to set reasonable estimates despite the pressure to try to go fast.

Techniques

Uncle Bob introduces several techniques to incorporate your team in determining realistic estimates.

Flying Fingers - A technique that's been mentioned in a previous post. Team members sit around a table and tasks are discussed. For each task, the team is asked for optimistic, nominal, and pessimistic estimates by raising their fingers based on how long they believe the task will take. If everyone agrees, then they go onto the next task. If there disagreement, then they continue discussion until an agreement is reached. Simultaneity of revealing fingers is very important in this technique as peoples' minds can be swayed based on what they see other people do.

Planning Poker - Systematically equivalent to flying fingers, except team members are given a hand of cards with different number on them. Members choose a card that matches their estimates, and sets the card faced down on the table. When everyone has decided, the cards are simultaneously revealed.

Affinity Estimation - All tasks are written onto cards, without any estimates showing. Team stands around a table with cards spread out randomly, and members sort the cards relative to one another. Tasks that take longer are moved to the right, and smaller tasks are moved to the left. This method is done in silence, and any member can move any card at any time. If any card is moved more than n times, the card is set aside for discussion. Eventually discussion of the order of the tasks begin, and lines between the cards are drawn to present bucket sizes. Traditionally, five buckets are drawn in a Fibonacci sequence.

While these techniques aren't the only methods to determining estimates, they are methods that have been proven to be effective in creating practical estimates.

The Law of Large Numbers

Estimates are not error-free and when facing a large task, it is often beneficial to break the task into several smaller tasks to minimize error. An implication of the Law of Large Numbers suggests the following:

If you break up a large task into many smaller tasks and estimate them independently, the sum of the estimates of the small tasks will be more accurate than a single estimate of the larger task.

While doing this still won't guarantee an error-free estimate, it is good practice to break the tasks up to better understand the task as a whole and to uncover any surprises that may arise.

Pressure

The business will always want commitments because they want to eliminate risk. We are honor bound to help the business find a way to meet commitments. However, we are not honor bound to accept the commitments.

So how do you avoid pressure? Business may be down your neck about having this and that done and you're stressing out. The best way to stay calm under pressure is to avoid the situations that cause pressure. Unrealistic commitments thwarts the goal of eliminating risk, so accepting them just does a disservice to both the business and you.

You may be tempted to rush and drift away from your disciplines and beliefs to meet deadlines. Don't! In doing so, you'll only cause messes that will only create more pressure down the road. You can avoid presure by keeping your system, code, and design as clean as possible by sticking to your disciplines at all time.

You can't always avoid pressure though, and it's important to handle pressure appropriately. When faced with pressure, don't panic. Manage your stress, think the problem through, and work at a reasonable and steady pace. Rushing will only drive you deeper into a hole. Communicate with your team to let them know that you're in trouble. In doing so, you can receive help from others and they won't be greeted with any surprises.

The only way through the pressure cooker is to rely on what you already know works - your disciplines.

Again, trust your disciplines. There is never a time to question or abandon them, and they are there to guide you through times of high pressure. Finally, get help! Pair with your peers to help you think of helpful ideas, point out any mistakes, and help you keep focused to drill through your program.

Creating and meeting deadlines can cause a lot of pressure and stress. Professionals remain calm and collected when the going gets tough, and it's how you deal with this pressure that sets you apart from nonprofessionals.

[nedyaj-blog]

Ain't Nobody Got Time for That!

Given that you spend the standard eight hours on a workday to be productive, how do you use this time wisely? Time management has always been a bit of a struggle for me as I'm sure it is for many people, and in this chapter of The Clean Coder, Uncle Bob discusses different types of meetings and ways to effectively manage time.

Meetings

There are two truths about meeting.

Meetings are necessary.

Meetings are huge time wasters.

Often these two truths equally describe the same meeting.

Professionals should be aware of the high cost of meetings and the importance of their own time. Because there are two truths to every meeting, it is crucial to plan ahead and figure out what meetings don't have a significant benefit to attend by knowing what will be discussed. Uncle Bob advises to decline any meeting that doesn't require your attendance as your projects hold the utmost importance. Likewise if you do find yourself in a meeting that isn't beneficial to you, find the best opportune time to politely leave the meeting.

Uncle Bob also introduces a few types of meetings that are part of Agile development: stand-up meetings, iteration planning meetings, and iteration retrospective and demo meetings.

Stand-Ups

Stand-up meetings require the participants to stand while the meeting is in session and have each person answer three questions:

What did I do yesterday?

What am I going to do today?

What's in my way?

Since starting my apprenticeship, I've participated in stand-ups everyday at 11AM to answer these three questions. Initially I thought it was an odd thing to do, but as the days went by my perception of stand-ups has changed into thinking that it's a great way of facilitating communication amongst team members and identification of issues before they become too problematic. Since I'm the only apprentice in Los Angeles so far, I feel like my participation in stand-up meetings doesn't contribute much to the team, but I can definitely see how beneficial it is to the craftsmen to have a quick formal meeting at the same time everyday to communicate with one another.

Iteration Planning

Iteration planning meetings are conducted to select the backlog items that will be executed in the next iteration. Estimates should already be done for each item and acceptance tests should already be sketched out. Uncle Bob states that these meetings are difficult to do well, and suggests that they should take no more than 5% of the total time of the iteration.

Iteration Retrospective and Demo

Conducted at the end of each iteration, retroactive (retro) meetings are meant for team members to discuss what went right, what went wrong, and actions to make these wrongs into rights. Stakeholders then see a demo of the newly working features to provide critique and feedback to the team members. I sat through a retro meeting today where the craftsmen discussed and listed the happy faces (right), frowny faces (wrong), and action items to turn those frowns upside down. It was cool to see that each participant had a say in how they thought the iteration went and to see how they came up with solutions to each issue.

Pomodoro Technique

Uncle Bob also talks about one effective time management technique that I've actually used for some time called the Pomodoro Technique. The instructions are pretty simple and are laid out below:

Set a timer for 25 minutes, or one tomato.

Let nothing interfere with what you're doing.

When time's up, stop what you're doing immediately, deal with any interruptions that occured during the tomato, and take a short five minute break.

Repeat. Every fourth tomato, take a longer break of 15-30 minutes.

This technique is very well-known and its popularity is justified. Ever since I started employing this technique, I feel like I've been a lot more productive than when I didn't use it. It's an effective way of keeping me engaged in my task because it makes me look forward to these breaks and cranking through four tomatoes to take longer breaks. Plus, it helps in keeping procrastination to a minimum, which is a nice side effect.

[nedyaj-blog]

Acceptance Tests and Testing Strategies

For the sake of brevity and saving time, I'll be bunching up the summaries of chapters 7-8 into one post since they both have to do with testing.

Acceptance Tests

In this chapter of The Clean Coder, Uncle Bob explains who should be involved in acceptance tests, what they are, when they should be written, how they should be done, and why this all matters.

Who Should Write Acceptance Test?

Ideally, stakeholders and QA collaborate to write the tests and developers verify them. In this way, (all) ambiguity is removed from the requirements and everyone involved understand the plan for system behavior.

What are They?

By definitions, acceptance tests are tests written by the collaboration of the stakeholders and programmers in order to define when a requirement is done. Everyone has their own definition of "done-ness", but Uncle Bob suggests that doneness is achieve when these three conditions are met:

All code is written

All tests pass

QA and the stakeholders have accepted

When Should They be Written?

According to Uncle Bob, the first few acceptance tests should be ready for the first iteration. By the midpoint of the iteration, all acceptance tests should be ready.

How Should They be Done?

Acceptance tests should always be automated. You create a set of automated tests that meet all of the conditions above; and if they pass, then you are done with that particular feature.

Why are Acceptance Tests Important?

When multiple parties are involved in the creation of a system, there is bound to be miscommunication and ambiguity. Acceptance tests exist to eliminate these issues by formally presenting the requirements that specify system behavior from a business standpoint. The audience of these tests is the business and the programmers. They are not to be confused with unit tests, which describe the lowest level of structure and are meant to be writtten for programmers only.

Testing Strategies

The image above represents the Test Automation Pyramid which illustrates the kinds of tests used during development. In addition to unit tests and acceptance tests, there exists higher-level tests to prevent QA from finding any errors and bugs in the system. Because QA work with the stakeholders to create automated acceptance tests that specify the requirements of the system and employ exploratory testing to characterize the true behavior of the running system, it is the responsibility of the professional programmer to ensure that QA finds (asymptotic) nothing.

Unit Tests

Written by programmers for programmers, unit tests specify the system at the lowest level. They provide nearly 100% true covereage of the code and assert its behavior.

Component Tests

Acceptance tests, as described above, are on this level of the testing pyramid and are written against individual components of the system. A component test wraps the component and tests that the output matches the input. Any other components are decoupled from the test using mocking and other appropriate techniques. These tests cover approximately half of the system.

Integration Tests

Used only for larger systems and typically written by system architects, integration tests ensure that all components are properly connected and can clearly communicate with one another. These tests are typically not executed as part of the Continuous Integration (CI) test suite, and are instead run periodically as prescribed by their authors.

System Tests

System tests execute against the entire integrated system and ensures that the whole system is wired correctly. Written by system architects and technical leads, these tests are written in the same language and environment as the integration tests and are executed rather infrequently. Because system tests ensure proper construction of the code, they only cover roughly 10% of the system as the behavior of the components of the code has already been tested by the lower levels of the pyramid.

Manual Exploratory Tests

Manual exploratory tests are human-driven and explore the system for unexpected behaviors while confirming the expected. These tests are not to be automated, and provide the assurance of knowing that the system behaves under human operation.

It's interesting to note how many types of tests there are when developing a system. Prior to reading these chapters, I didn't know the progression of the testing process and the purpose of each test. I have no experience in writing tests (yet), but I'm excited in learning the ins and outs of the proper way of software development to become a clean coder.

[nedyaj-blog]

Practice Makes (Asymptotic) Perfect

Doing your daily job is not practice - it's performance.

Practicing programming is definitely something I need to do more. Before I opened this book, I foolishly thought that just doing my daily tasks were sufficient enough to be considered as "practice". I never really thought of programming practice as the same thing as the way musicians and performers practice, but it really does make sense. These people practice on their own time and consider work time as performances, why should I think any differently?

There are several different ways to practice programming:

Kata A precise set of choreographed keystrokes and mouse movements that simulates the solving of some programming problem. The kata serves not as a practice of problem solving, but to practice the movements to make them automatic and instinctive so that they are there when you need them.

Wasa Also known as ping-pong. Two programmers choose a kata. One programmer writes a unit test, and then the other must make it pass. Switch roles and repeat.

Randori Similar to wasa, but with many people. With a screen projected on the wall, one person writes a test and then sits down. The next person makes the test pass and then writes the next test. Repeat.

Open source Broaden experience and diversify tool/skill set by contributing to open source projects and using tools and languages that aren't familiar.

I think out of these practice methods, randori seems the most interesting and fun. It's always nice to see how other people tackle the same problem and it's a great way to learn different ways of thinking.

[nedyaj-blog]

Test First

The concept of test-driven development (TDD for short) is very foreign to people like me who just wrote code without tests. There are three laws of TDD:

You are not allowed to write any production code until you have written a failing unit test.

You are not allowed to write more of a unit test than is sufficient to fail - and not compiling is failing.

You are not allowed to write more production code that is sufficient to pass the currently failing unit test.

Rinse and repeat into a cycle that, according to Uncle Bob, is about 30 seconds long. It seems weird to write failing tests first before writing actual code, but after Dave had asked me to try my hand at writing a few tests after I had already written my Tic-Tac-Toe code, I began to see why testing first is necessary. Before getting into the why, here are a few benefits of TDD:

Certainty If you make any changes in your code and all tests still pass, you can be nearly certain that the changes made have not negatively affected other parts of your code.

Low Defect Injection The number of bugs and issues remain low as you add to and update your code.

Courage Gives you the confidence to change code and eliminates the fear of breaking it. Regularly cleaning and fixing your code makes it become simpler and easier to maintain/extend.

Documentation Unit tests are essentially the user manual to your code. For anything you need to know how to do, there will be a unit test that describes it in detail.

Design Forces you to think about good design and isolate/decouple functions so that you can write tests.

Design was the biggest reason why I thought testing first is crucial. Writing tests for my Node class wasn't all too bad, but once I started getting into the more complex functions like those in my Board class, things started to get difficult. I had no idea how to start writing tests on a lot of functions because there were too many dependencies on other objects and functions. I read about stubs and mocks, but everything flew over my head. In the end, I couldn't completely finish writing all of my tests and I knew it was because I was attempting to write them after I wrote my code. The problem was that I was just writing these tests to get them to pass, and I didn't have to think about the design and flexibility of the code. As Uncle Bob put it, the tests you write later are defense, and the tests that you write first are offense. Testing first ensures that your code is dynamic and future proof to any changes or additions that will eventually be made.

Writing tests first makes more sense now after reading this chapter, and I'm very excited in learning and practicing TDD to write better code.

[nedyaj-blog]

Principles of Coding

This chapter was an interesting one that discussed a set of rules that Uncle Bob adheres to when coding. I'm glad that he stated that these rules were to be taken with a grain of salt, because there were some points with which I didn't fully agree: avoiding "The Zone" and listening to music while coding.

Uncle Bob argument against coding in the flow zone is that you lose some of the big picture and will likely make decisions and write code that may need to be revisited. Maybe it's because I haven't been writing code nearly enough as Uncle Bob has, but I definitely feel much more confident and focused when in "The Zone". I also feel more focused and able to concentrate better when I have some background music, but the type of music definitely affects my ability to focus. I am a big fan of Trance and other sub-genres of EDM, but I definitely can't listen to this kind of music when I'm trying to concentrate. I typically need music that is more chill and lacks lyrics to help me focus.

Other than these two differing opinions, I enjoyed reading the rest of the chapter. Uncle Bob lays out some great advice and tips about when you shouldn't code and how to alleviate stress and anxiety that makes writing code impossible. He also teaches you how to pace yourself, and how to manage your time and learn your limits when dealing with overtime. and deadlines.

"Nothing can bring a young software developer to high performance quicker than his own drive, and effective mentoring by his seniors. [...] Young programmers have a professional duty to seek out such mentoring from their seniors."

I've definitely learned a lot in this chapter, but the one thing I really need to work on (among many other things) is learning how to ask for help. Uncle Bob mentions the stereotype that programmers tend to be arrogant, self-absorbed introverts who require disciplines that drive them to collaborate. I'd like to think that I'm not arrogant or self-absorbed, but I can definitely relate to the introvert trait. I've been working on my interpersonal skills, but I still consider myself shy and reserved. I feel like a burden when I ask for help, and I try not to seek assistance unless I absolutely need it. I need to learn that it's okay to ask for help and be dependent on others. This apprenticeship is an amazing opportunity given to me in order to further my education and really learn how to code the right way. In order to take advantage of it, I need to use all of the resources available to me and seek help from mentors when I need help. I'm still unsure of what Dave will have me doing since I haven't started my apprenticeship yet, but I will work on learning how to ask for help by the time I get the hang of things. (See what I did there?)

[nedyaj-blog]

Language of Commitment

There are three parts to a commitment:

You say you'll do it

You mean it

You actually do it

Recognizing the language of the lack of commitment is an important skill to have when expecting someone to get something done. Some examples include:

Need/Should "I need to start exercising." "I should eat better." "Someone should do something."

Hope/Wish "I hope I get this done by tomorrow." "I wish I had the patience to do that."

Let's "Let's hang out sometime." "Let's get this done."

We encounter this kind of language every single day and often find that not many people go through all three stages. These words and phrases convey a lack of control or personal responsibility to these commitments.

"The secret ingredient to recognizing real commitment is to look for sentences that sound like this: I will... by... (example: I will finish this by Tuesday.)"

The difference between this example and the phrases above is that it's a statement of fact about something you will do by a set time. You are taking full responsibility for this promise and you will get it done. It's difficult and sometimes scary to commit to something using this kind of sentence because there really is no way out once it's all said and done. The person you've committed to is expecting this promise to be carried through. This helps in pushing you to go through the other stages of commitment: meaning it, and following through with it.

You can't always get things done on time and that's okay, things happen. What separates professionals to non-professionals is that a professional will still commit to actions that will bring him closer to the finish line and raise red flags immediately as soon as possible. The earlier you tell someone about a potential issue, the more time there is to reassess the situation and make decisions.

"Breaking disciplines only slows us down."

A professional should never skip critical steps in an attempt to make a deadline. He has a responsibility to maintain and uphold certain standards. When learning how to say "yes" and taking on commitments, it's important to know your limits and know the costs of your actions. While a professional is not expected to say yes to everything, he should work hard to find solutions to make it possible.

I hear things like "I should eat better" and "Let's hang out sometime" so often that I never take the person seriously, and it's interesting to read why these non-commitments are phrased this way. I enjoyed reading this chapter of The Clean Coder because it really made me stop and think about how I phrase commitments to others, and how I can still uphold a promise even if I can't completely follow through on time. Although I still have a long ways to go, as an aspiring professional, I am confident that this book will help me reach my goal.

[nedyaj-blog]

Just Say No!

I have a pretty hard time saying no to people who ask for favors, or when asked to do something that I may not be able to do. I was scared to disappoint others and I'd often agree to do something with uncertainty or tell people that I'd try to get something done. Chapter 2 of The Clean Coder was a very insightful read, and I've learned that saying yes or I'll try is detrimental in the workplace - especially when the stakes are the highest.

"Professionals speak truth to power and know how to say no to their managers."

Hard decisions are best made when there is confrontation and negotiation involved, as a professional would have different objectives than his manager. One must pursue and defend one's position as aggressively as possible so that the best possible outcome is reached between two adversaries.

"If you are not holding back some energy in reserve, if you don't have a new plan, if you aren't going to change your behavior, and if you are reasonably confident in your original estimate, then promising to try is fundamentally dishonest. You are lying. And you are probably doing it to save face and to avoid confrontation.

I think this is one of my favorite quotes of this chapter. I never really thought about the consequences of saying I'll try when tasked to do something that I was uncertain about. I never thought about the repercussions of not saying no when I knew something was impossible to achieve because I was afraid of letting others down. After reading this chapter, I know now that this kind of behavior is highly unprofessional and that I need to learn to not be afraid to say no.

[nedyaj-blog]

The Clean Coder

Last week, I was given a list of books to start reading before I officially begin my resident apprenticeship with 8th Light on the 11th. My mentor, Dave, had asked me to start with Uncle Bob Martin's The Clean Coder, and to write a blog post about each chapter. I decided to invest in a Kindle Paperwhite, and just got the device and book today. I haven't kept a blog since the good old Xanga days, but hopefully I won't be so boring!

What is a software professional? Until I started reading The Clean Coder, I had never really thought about what makes a professional software developer. Is it the way he dresses? How many languages he knows? Number of years in the industry? The first chapter defines professionalism with two terms: responsibility and accountability. Here's a list of what I've learned in this chapter:

Take responsibility early and think of the customer and the company over saving your own face

Learn to apologize

Do not release code you're uncertain about

Test. Test. Test!

Code should be flexible and must be resilient to change. Make small lightweight changes to the code whenever you see it (Boy Scout Rule)

You're responsible to continuously learn and remain marketable

40 hour work week + 20 hours for self-development = 60 hours a week dedicated to your career!

Minimal list of what you should know to be a professional:

Design patterns - All 24 Gang of Four patterns

Design principles - SOLID and component principles

Design methods - XP, Scrum, Lean, Kanban, Waterfall, etc.

Disciplines - Test-Driven Development, Object-Oriented Design, etc.

Practice! Doing your daily job is performance, not practice

Do repetitive small exercises, or katas, to train fingers and brain

Collaborate with others (pair programming)

The best way to learn is by mentoring others whom you are responsible for

Understand the domain of the program solution - Know enough to recognize and challenge specification errors

Employer's problems are your problems. Imagine yourself in his/her shoes.

A professional is arrogant and confident, but knows that he is human and will fail and make mistakes. Laugh it off when criticism is deserved.

Oh man, I've got a long way to go before I can call myself a professional. I'm not gonna lie, I felt pretty intimidated after reading this chapter. Although I recognize and know some terms of the minimal list of things to know, I definitely have a lot of studying to do. Even though I feel like I'm behind and slightly overwhelmed (60 hrs/week?!), I'm really excited to work hard and I can't wait to begin my apprenticeship next week.