Are you doing all you can to further your career as a software developer? With today's rapidly changing and ever-expanding technologies, being successful requires more than technical expertise. To grow professionally, you also need soft skills and effective learning techniques. Honing those skills is what this book is all about. Authors Dave Hoover and Adewale Oshineye have cataloged dozens of behavior patterns to help you perfect essential aspects of your craft.
Compiled from years of research, many interviews, and feedback from O'Reilly's online forum, these patterns address difficult situations that programmers, administrators, and DBAs face every day. And it's not just about financial success. Apprenticeship Patterns also approaches software development as a means to personal fulfillment. Discover how this book can help you make the best of both your life and your career.
Solutions to some common obstacles that this book explores in-depth include:
Burned out at work? "Nurture Your Passion" by finding a pet project to rediscover the joy of problem solving. Feeling overwhelmed by new information? Re-explore familiar territory by building something you've built before, then use "Retreat into Competence" to move forward again. Stuck in your learning? Seek a team of experienced and talented developers with whom you can "Be the Worst" for a while.
"Brilliant stuff! Reading this book was like being in a time machine that pulled me back to those key learning moments in my career as a professional software developer and, instead of having to learn best practices the hard way, I had a guru sitting on my shoulder guiding me every step towards master craftsmanship. I'll certainly be recommending this book to clients. I wish I had this book 14 years ago!" -Russ Miles, CEO, OpenCredo
Think of Apprenticeship Patterns as a bugfixing patch for Pete McBreen's "Software Craftsmanship"
While reading McBreen's book, it becomes clear after a while that what he is describing is an ideal, something of a "this is the way that the software industry ought to work" and while reading it I couldn't help but agree, it ought to. However, the real world is so vastly different from McBreen's utopia that it often feels hopeless, like a lot of the great benefits of the book are out of reach because of constraints of the real world.
Apprenticeship Patterns aims to fix this, by showing how apprentice software craftsmen can benefit from the ideas even in the real world. It accomplishes this goal very well, grounded in pragmatism but relentlessly adamant about how software professionals can live.
The book is organized like a Design Patterns book, with individual named patterns and a formula to each section. This feels somewhat like a square peg in a round hole, but the strange format doesn't distract from the book's content, which is excellent. Though there are a lot of common sense patterns and a number of "I've seen this before" patterns, the book has a lot of new stuff, a lot of great suggestions, and is overall a well-organized wealth of advice for programmers who take themselves, perhaps, a bit too seriously. I highlighted a LOT of stuff.
I'd actually recommend this book above McBreen's, which I really enjoyed, largely because it's so pragmatic, and avoids pie-in-the-sky idealism so well. Software developers can read this book and start bettering themselves immediately. And don't think that, since it's for "apprentices" that you're too good for it, the book makes a strong argument that you are probably an apprentice, at best (and, spoiler alert, that there are no masters yet).
Вдъхновяваща книга, която трябва да ви изпълни с ентусиазъм за промяна и развитие. Успях да извлека няколко поуки, които ще опитам да приложа в практиката си, но ще почакам малко и ще им направя повторно ревю.
Книгата ми казва, че технологиите, с които се занимавам са стари и за да стана по-добър трябва да зарежа старите знания и да уча нови. Книгата ми казва, че трябва да се заоградя с по-добри от мен програмисти и да ги напъвам да ми споделят знания. ОК. Точно така работят нещата при 2 категории хора, които никой не обича - програмистите, които никога не се задържат на дадено място и досадниците, които не четат manuals.
Apprenticeship Patterns has been a pivotal book in my software career. Many years ago I heard about one of the patterns in this book called "Read Constantly." It was in a video of a talk by the author of this book, Dave Hoover. The pattern stated that reading a good software book every two months would distinguish anyone in a year from other developers. This stuck with me and inspired me to start reading more. After many years and many books, I'm deeply grateful to have been introduced to Apprenticeship Patterns by my colleagues. And I'm excited for the launch of our Women Apprenticeship Program at Nulogy next month.
I could have benefited from reading this book earlier. It’s not focused on technical but more on personal, concerning your motivation and morale. There are lots of parts that made me pause, think, reflect and write the important keys. But this really struck me most:
After all, there’s no certificate for “Master Software Craftsman.” Being a genius, lucky, rich, or famous doesn’t make you a master. These things aren’t essential to craftsmanship. Skill across all facets of software development and the ability to transmit that skill in ways that move the discipline forward are at the heart of the craft. If a person is able to train others to equal or surpass her skills, then it becomes evident that person is a potential master.
Apprentices are people who are willing to take on a junior role that maximizes their learning opportunities, as opposed to people who try to climb as quickly as they can into roles that maximize their financial opportunities. In my experience, if the apprentice has talent and the right attitude, their financial success will inevitably follow their learning success. ========== “I want to change the way people think about programming,” Kent said. I agreed. We both wanted to reverse what we thought had been a wrong turn in the progress of our industry. And, amazingly, we did it. ========== The strongest patterns are the ones that are applied productively over and over again. ========== Patterns don’t have to be new to be useful. In fact, it’s better if they are not new. ========== Well, we’ve overloaded our profession with resources. ========== So, why this book now? Well, we’ve overloaded our profession with resources. There is more information available about our revolution than any one person can absorb. Still, some people manage to do it. They internalize all the advice available to them and always seem to have it close at hand. How do they do achieve that level of mastery? This book is full of patterns for mastering our complex field. Mastering is more than just knowing. It is knowing in a way that lightens your load. ========== All the advice that has come out of our revolution does not help much until it becomes second nature. The craftsmanship movement in software recognizes that making this stuff second nature isn’t, well, second nature. These patterns are a welcome contribution to this progression. ========== He who knows not and knows not that he knows not, is a fool — shun him! He who knows not and knows that he knows not, is unlearned — teach him! He who knows and knows not that he knows, is asleep — awaken him! He who knows and knows that he knows, is enlightened — follow him! ========== A pattern is a named description of a recurring solution to a problem in a given context. ========== Patterns are meant to be open to modification to fit your circumstances rather than mechanically applied. ========== As with all pattern languages, you should be careful not to overuse these patterns. Don’t look for excuses to use every single pattern, but instead pick and choose the most appropriate set for your situation. ========== book—you can dip into it for inspiration from time to time. ========== This book is written for software apprentices—for people who have had a taste of developing software and want to take it further, but need some guidance. ========== There are many other books we would recommend for people in those roles, but this book is for people at the beginning of the journey. ========== The journey discussed here starts with “Hello world!”, but where does it end? Far too often, it ends with a promotion to middle management. ========== The journey discussed here starts with “Hello world!”, but where does it end? Far too often, it ends with a promotion to middle management. Too many talented people thoughtlessly take that promotion and find themselves just a few years later in jobs they don’t enjoy and yearning for retirement. But for those who have a knack for developing software and enjoy the learning process, software development is a career that can last a lifetime, and it can be a great ride. ========== For any programmer proficient in his first language, it’s always a temptation to fall back to the standards and idioms of your native language when you’re learning a new language. ========== Our goal here is not simply to hand people a rule book, but to give them the ability to create new practices for new contexts, which in turn drives the discipline of software development forward. ========== An attachment to Carol Dweck’s research, which calls for a “growth mindset.” This entails a belief that you can be better and everything can be improved if you’re prepared to work at it. In her words, “effort is what makes you smart or talented” (Mindset, p. 16), and failure is merely an incentive to try a different approach next time. It is the opposite of the belief that we’re all born with a given amount of talent, and that failure is an indication that you don’t have enough of it. ========== A need to always be adapting and changing based on the feedback you get from the world around you. ========== A desire to be pragmatic rather than dogmatic. ========== A belief that it is better to share what we know than to create scarcity by hoarding it. ========== A willingness to experiment and be proven wrong. This means we try stuff. We fail. Then we use the lessons from that failure in the next experiment. ========== A dedication to what psychologists call an internal locus of control. This involves taking control of and responsibility for our destinies rather than just waiting for someone else to give us the answers. ========== Instead, we think that a useful system should be able to identify and absorb the best ideas from all elements of the software development community. ========== “I guess it basically means having the attitude that there’s always a better/smarter/faster way to do what you just did and what you’re currently doing. Apprenticeship is the state/process of evolving and looking for better ways and finding people, companies and situations that force you to learn those better/smarter/faster ways.” ========== “It is not an internal quantity that is fed by easy successes and diminished by failures.... It is not something we give to people by telling them about their high intelligence. It is something we equip them to get for themselves—by teaching them to value learning over the appearance of smartness, to relish challenge and to use errors as routes to mastery” ========== you must learn to grow yourself, to learn how you learn. ========== At some point, an apprentice is approached by a master or a journeyman and told that her work and her role in the community are that of a journeyman. In such a case, the apprentice had previously begun taking on more responsibilities, and like a “boiled frog” had made a gradual but not discrete transition from one state to another. That transition may take longer for some people than for others. For some, the transition may take longer than their professional careers. ========== The journeyman’s responsibilities are wider than those of an apprentice. As such his failures can do more harm. Some of the patterns we will discuss are not appropriate for a journeyman, precisely because he has a greater responsibility to others who may see him as a mentor. ========== They might be facing overbearing and/or incompetent managers, de-motivated coworkers, impossible deadlines, and work environments that treat novice developers like workhorses, storing them in small, rectangular stalls with a PC and a crippled Internet connection. ========== An apprenticeship is a season in your career when your focus is more on your own growth than almost anything else. ========== The more experience you already have, the more effort you will need to put into “emptying your cup,” clearing your mind of bad habits, setting aside the pride you have in your skills, and opening yourself up to the different, often counterintuitive, approaches of your more experienced colleagues. ========== One of the fundamental ways to improve the experience of learning your first language is to have an actual problem to solve. ========== It is possible to learn a language on your own, but it takes a long time to learn the spirit of a language unless you interact with experts. ========== One danger of digging deep into your first language is getting stuck. It likely will remain with you throughout your career as your native tongue. ========== Apprentices comfortable with an object-oriented language should explore a functional programming language. Apprentices comfortable with dynamic typing should explore static typing. Apprentices comfortable with server-side programming should explore user interface design. ========== You shouldn’t be wedded to any particular technology, but have a broad enough background and experience base to allow you to choose good solutions in particular situations. ========== never stopping to think that the freedom to be foolish might well be one of the keys to the genius’s success. ========== Find an opportunity to unlearn something. Ideally, this would be something that forces you to put aside your previous experience. ========== Ask that person to explain some of the misconceptions that people from your particular background usually have about their community. ========== Despite (and because of!) your inexperience, you bring some unique attributes to your team, including an infectious enthusiasm. Do not allow anyone to dampen your excitement for the craft—it is a precious commodity and will accelerate your learning. ========== They either repress their enthusiasm altogether, or allow it to manifest only outside of their day jobs. ========== Comprehension can be increased if more levels of experience are connected, as when newcomers who take nothing for granted interrelate more often with old-timers who think they have seen it all. ========== Craftsmen learn from the apprentices, even as the apprentices learn from them. Enthusiastic beginners not only renew the craftsmen, but also challenge the craftsmen by bringing in new ideas from the outside. A well chosen apprentice can make even a master craftsman more productive. ========== Collect the CVs of people whose skills you respect. ========== According to research by the social psychologist Carol Dweck, the need to appear competent is ingrained into people of most industrialized societies. ========== Software craftsmen build their reputations through strong relationships with their clients and colleagues. ========== Expertise is a by-product of the long road we’re all on, but it is not the destination. Over the course of their journey, craftsmen will work with countless technologies and domains. ========== However, as an apprentice with aspirations to mastery, you need to be willing to Expose Your Ignorance as well. ========== Remember that learning in public is one of the ways in which an apprentice begins the transition to journeyman. It’s a small step from learning where people can see you to teaching. ========== One of the distinguishing facets of the craft approach is a willingness to put the wider interests of your community before your own, rather than using the team and the client to further your personal growth. ========== This new knowledge you have may reveal gaps you hadn’t noticed before; don’t forget to add these things to your list. ========== It’s your responsibility to offset the risks of this approach by Finding Mentors and Kindred Spirits who can provide help when you need it. ========== Dave saw that although these exceptional people were miles ahead of him, they were all walking the same road. ========== you should keep in mind the expectation that you will be a working software developer even when you are middle-aged. ========== And rather than counting the days to retirement, the craftsman will willingly and joyfully work into her final decades. ========== Imagine that 40 years from now you are asked to write a short description of your professional history and the biggest influences on your path. Use the output from that thought experiment to help you plan your future career choices. ========== The things we build for customers can be beautiful, but must be useful. ========== utility and beauty are not opposed, but interdependent. ========== Sometimes you will make the wrong trade-off, and fixing that mistake by rewriting the system from scratch may not be in the customer’s best interest. In those situations you will need to develop the ability to refactor and repair. ========== Anyone who has ever seen a programmer at work...knows that programming itself, if the programmer is given the chance to do it his way, is the biggest motivation in programming. ========== “I’d like to learn something new, but what I already know pays too well.” ========== Your mother might think you deserve it, but impressive titles and responsibilities do not indicate that your apprenticeship is over. ========== more time with your family or more money, or perhaps a new vocation has captured your attention. ========== If and when they came back, we welcomed them with open arms because those experiences had given them new perspectives they could share. Sadly, conventional software organizations may not be so welcoming. They often see these detours as suspicious gaps in your career that you must justify. They will expect you to have a rationale that makes sense within their value system for why you left and why you’re coming back. ========== Be the lion’s tail rather than the fox’s head! ========== Organizational cultures that encourage software craftsmanship are rare. ========== Humility is one of the foundations of a successful apprenticeship. Combined with ambition, humility will help keep you focused and progressing in the right direction. ========== Andy Hunt, a highly respected software craftsman, has asserted numerous times that software development is composed of two primary activities: learning and communication ========== We would build on that idea and assert that the core theme of an apprenticeship is learning and the dominant trait of a successful apprentice is a demonstration of her learning abilities. ========== The only people who achieve much are those who want knowledge so badly that they seek it while the conditions are still unfavourable. ========== Apprentices are thirsty for opportunities to replace their ignorance with skill. ========== A good way to ensure you have interesting exercises to use in your practice sessions is to trawl through old books like Programming Pearls, More Programming Pearls, or Etudes for Programmers. ========== Over time, maintaining a wiki can teach you about HTTP, REST, parsing, web design, caching, full-text search, databases, and concurrency. ========== Your notebook, blog, or wiki should be a nursery, not a graveyard—lessons should be born from this record, rather than going there to die. ========== Early in your apprenticeship, develop the habit of regularly sharing the lessons you have learned. This may take the form of maintaining a blog or running “brown bag” sessions amongst your Kindred Spirits. ========== Furthermore, teaching is a powerful learning tool for the person doing the teaching, perhaps even more so than for the students. Thus the old saying “When one person teaches, two people learn.” ========== Ingenuity is often misunderstood. It is not a matter of superior intelligence but of character. It demands more than anything a willingness to recognize failure, to not paper over the cracks, and to change. It arises from deliberate, even obsessive, reflection on failure and a constant searching for new solutions. —Atul Gawande, Better ========== Failure is inevitable. It happens to everybody sooner or later. In fact, someone who has never failed at anything has either avoided pushing at the boundaries of their abilities or has learned to overlook their own mistakes. ========== Be sure to intermingle classics with modern, pragmatic books and/or articles in your Reading List. ========== This means that the next time someone talks to you about Representation State Transfer, better known as REST, you should take that as an excuse to read Roy Fielding’s PhD thesis in which he defined the concept. ========== Armed with your deeper knowledge of HTTP, try to implement a client and a server for RFC 707. ========== We can guarantee that the tools you use as an apprentice will be obsolete by the time you become a journeyman. In time, all of your favorite tools will become junk. For your career to prosper, you must learn to acquire and abandon familiar tools with ease. ========== When we say that something is a craft, one of the things we mean is that it is a discipline and a tradition that places a high value on skill. This includes acquiring, growing, and eventually transmitting that skill. We believe true mastery is shown in the effect you have on others by transmitting your superior skill. ========== In software development, we don’t know exactly what constitutes mastery, but we do know what it isn’t. ========== As an apprentice, you should aim to become better than your teachers. And if they are good teachers, they should try to help you achieve that goal. ========== Mere genius is not mastery, but if a person is able to train others to equal or surpass her genius, then it becomes evident that person is a potential master. ========== there are no masters...yet. ========== Working with masters is the best way to learn a craft. ==========
This entire review has been hidden because of spoilers.
This book came as a recommendation to me, as I found this as an appropriate time to read it. One of The greatest messages that stuck out to me was, as you are starting your journey as a software developer, reading the right book at the right time significantly impacts your personal development. This was definitely the best time to read it, which in turn provides me a list of great books to be read.
I will also conclude that some of the concepts are harder to grasp if you're not already slightly familiar with software terminologies and a world of resources that exist. But the more you explore these resources as you read is inspiring to see that such an opened and welcoming community exist.
"Perpetual Learning can be viewed as a blessing or a curse. Learning something new can be painful, especially when it's done under pressure and with little guidance. Yet, like the athlete that must endure muscle soreness after strenuous workouts, the software developer endures the mental dissonance that comes with learning something new. That dissonance can become a welcome sign of progress. Self-reflection, identifying failure through feedback loops, and learning your weaknesses all appear negative on the surface, but these patterns are helping you to reduce your ignorance. The alternative is to focus exclusively on what you already know, but this is not the way towards mastering software craftmanship; it is the way to specialization in a single expertise."
An absolute must read for anyone aspiring to be an excellent software craftsman, also for anyone managing developers or technical employees it's a good read so you can spot who's making the right moves and who is taking the long path to excel and not just sitting around and doing their job.
I recognised almost all the patterns in myself having done this for a long time.
Really useful book that sets out its information in the style of “patterns” which can easily be applied depending on the “contexts” you find yourself in. Though obviously tailored to software development, a lot of these patterns are also applicable to other skills, essentially any skill that involves a lifelong dedication to learning and mastery. I will be using these patterns in my both my software development and personal endeavours.
The subtitle of this book is "Guidance for the Aspiring Software Craftsman," and I really did not know why people railed against software craftsmanship until I read this book.
This book has a lot of approaches for beginning software developers to improve themselves by being humble, staying motivated, accurately assessing their skills, continuously learning, and reading deeper. It is a strange book that throws out a lot of things to assure a reader that the authors are smart without really explaining anything about the concepts that it is discussing. For example, last night, while reading this book, I asked aloud, "What is a Trie?"
Occasionally, this book used the word "she" as if a woman could potentially be a software craftsman. However, the people that they chose to quote were mostly men who are well-known for encouraging cult-of-personality around themselves. There were a lot of references to Hackers and Painters and a lot of books by Bob Martin.
There are a little over fifty books in the bibliography of this book. About four or five books by women are listed out of the fifty, and only a couple of those seem to be by women who do computer science. Pair Programming Illuminated by Laurie Williams is the only book that has a woman as its author, and I am not sure why she does not have a Wikipedia page. Ann Anderson is one of the three authors on Extreme Programming Installed.
This is important because the book discusses how you are only a craftsman when other people recognize you as a craftsman; and apparently, they do not think many women are craftsmen going by their bibliography.
I do think that some of the books in the bibliography that I have not read, like Refactoring to Patterns, should probably go on my reading list; but overall, I think I would have learned more reading something else.
As it usually happens in real, I only came across this amazing book several years from when I most needed it in my professional career. By the time someone referred me to it in 2014, I had already begun my long journey to become an apprentice and aspiring journeyman. I like to tell people that I learned things the hard way, getting my education from The School of Hard Knocks. To this day I still believe that the Sweep The Floor and Be The Worst patterns were designed with me in mind! Of course I didn't know that there were patterns to describe what my professional life going through, and maybe this was a good thing in the long.
This book should be mandatory for anyone setting out on their own journey to a new career. It is chock full great career advices and it just might change your life!
Just a so so book. It may be my personal opinion, but maybe because I've read a lot of articles and books about software craftmanship, so this book patterns seem quite obvious to me. Moreover, those patterns seem to be scattered to me, i just be able to remember some main patterns like: breakable toys, concrete skills, dig deeper.. But honestly, some points in the book are really helpful to me, it helps me know that the way how i'm currently pursuing to be a better developer is correct, and there are tons of great developers out there are doing the same with me, and that's really great.
I can guarantee that you won't be disappointed after reading this book. Not only it is well written, short and concise but it also contains many interesting and very useful ideas that we could apply in our work to help our skills grow and our career flourish.
I can only regret that I've read it after almost 7 years of work as a developer. It would be even more useful if I had done it at the early stage of my career.
As one of other readers wrote "Best development book I've read, has no code in it"
I think every developer should read this book. A handbook with a lot of good thoughts and best practices about our profession. Very inspiring. It sometimes describe an utopical world, but that's what you get when you have to push your optimism and your commitment to the limit. I think that also non-developers could benefit from a lot of the patterns described. Note: it's not a book just to read, you have to keep it on hand for when you need motivation.
Interesting, but much of it seemed like common sense. They completely skipped over work/life balance, which if you followed all the patterns in the book, would have a strong chance of getting completely out of whack.
When discussing what it means to be an apprentice, Marten Gustafson, one of our interviewees, put it best when he said, “I guess it basically means having the attitude that there’s always a better/smarter/faster way to do what you just did and what you’re currently doing. Apprenticeship is the state/process of evolving and looking for better ways and finding people, companies and situations that force you to learn those better/smarter/faster ways.”
Be the Worst Surround yourself with developers who are better than you. Find a stronger team where you are the weakest member and have room to grow.
A classic example of the use of this pattern is the multitude of people who have built their own wikis. A personal wiki is a great tool for the apprentice because you can use it to Record What You Learn. Wikis make good Breakable Toys because they can be incredibly simple§ and you can Use the Source to find countless examples to look. Over time, maintaining a wiki can teach you about HTTP, REST, parsing, web design, caching, full-text search, databases, and concurrency. If you stick with it long enough, it will also teach you about data migration when you eventually add a feature that requires a different storage format and you don’t want to throw away all your data. Other examples of Breakable Toys include games like Tetris and Tic-Tac-Toe (one of our excolleagues is in the habit of writing a game in every new language he learns), blogging software, and IRC clients. The essential point is that building the toy involves learning new things, giving you an opportunity to gain a deeper understanding of your tools in an environment that is both safe (since you are the only or most important user) and where there is still room for you to better serve your own needs as a user than even the slickest of commercial alternatives.
Use your favorite tools to build the world’s simplest wiki while still maintaining the highest standards of quality. The initial version doesn’t need to have anything more than a simple user interface that lets you view and edit plain-text files. Over time, you can add more features and find interesting ways to distinguish your wiki from the thousands that already exist. Do not be constrained by existing implementations; instead, let your professional interests guide you. For instance, you might have an interest in search engines; in this case your wiki could experiment with ranking algorithms or tagging. It really doesn’t matter what you decide to do, as long as you experiment and learn.
Pick an algorithmically sophisticated open source project such as a source control—system, for example, Subversion, Git, or Mercurial. Browse the project’s source, noting down the algorithms, data structures, and design ideas that are new to you. Now write a blog post describing the architecture of the project and emphasizing the new ideas you have learned. Do you see places in your everyday work where the same ideas can be applied?
Record what you learned to a blog. Read them again and again to remember
If you read even one good programming book every two months, roughly 35 pages a week, you’ll soon have a firm grasp on the industry and distinguish yourself from nearly everyone around you.
One of the ways to use this pattern is to get your information from primary sources. This means that the next time someone talks to you about Representation State Transfer, better known as REST, you should take that as an excuse to read Roy Fielding’s PhD thesis in which he defined the concept. Consider writing a blog post to clarify or share what you’ve learned, and to encourage others to read the original document as well.
It would have been good to come across this earlier in my career although that would need time travel since the book was written later. :-D
Useful advice but somewhere along the line I started to get the feeling that there is too much role play going on. I have long bought into the philosophy of considering writing software as your craft and on continuously working to improve it. And I was hoping there would be solid advice towards that here. But it turned out to be good advice wrapped in unnecessary terminology. Perhaps patterns is not the most suitable pattern here!
Some of the names can feel contrary to what they are proposing thus reducing their usefulness further. Consider "Expand Your Bandwidth" which suggests that you should jump head in into all sources of information when starting to learn something new, read the books, find online communities, find offline communities, blogs, podcasts etc etc. This is more like "Saturating Your Bandwidth" rather than "Expanding Your Bandwidth". May be "Plunge into the Scene" is better?
Another problem in Indian context is that it may reinforce the sense awe and respect for "seniors" among fresh starters, something we can all do without. This is not a problem on the book's part though. It clearly says that we are all on the long road to mastery, just that some of us started earlier and are further along. But the line between a healthy deference and hero worship can be thin.
Having said all that, I think it would still be a good read for people starting down this path. Ignore the pattern names, but pay heed to the advice. And don't forget to pick up Pragmatic Programmer that I found to be much more useful.
I found this book amazing. Some of the ideas are not new, but all of them seem valuable. They apply to different points along a career path so I can't test them all out now, but it was awesome to see what I'm already doing right, what other strategies I could add to my learning endeavors, and what I can keep in the back of my mind for much further down the road.
I believe this book could be helpful to anyone pursuing a craft skill - I think that's most skills that are not science or art. However, it's got a lot of software references so it might take a little work on the part of the reader to filter out those specifics. Of course, anyone who is willing to do that is probably the right kind of person to get a lot of benefit from this book.
If you're a software developer and have not thought much about how to learn and apprentice in the trade, this book is a must have. It will show you how to more quickly improve your skills on the path to mastery (or at least give the impression to others that you care about that sort of thing. Win-win, right?).
It is a good book with patterns written like the Design Patterns book by Gang of Four. But it starts off very much opinionated about software engineering. The writers tried to pass of software engineering as something sacred. However, as you go further, the view changes and they offer patterns to all types of software engineers. Some are very common, but a few were insights from experienced people that are still applicable in this day & age. Additionally, the writing style is very easy to read.
I would recommend this book to college students who are in their final year, fresh college graduates and junior software engineers.
This is not a typical advice book. It does, however, give you advice on how to improve your skills and how to avoid your self-development go stale. It does so by wrapping their experience and suggestions into a pattern template "context - problem - solution - personal experience (use-case)" and it works rather well.
Highly recommended for young professionals and seasoned programmers alike. It won't go easy, some "patterns" will read like a typical advice book and some will not match your "problem". However, once you read it, it is hard to deny you will change your perspective on your self and your future.
(I would have given it 4.5 stars if there was the option.)
I wish I had read this book few years ago, but then I'm not sure I had the right mindset at the time. Actually, I'm actually not sure how many apprentices are in the right mindset to consume this book as the begin their careers (very few I would imagine).
The book is a good read no matter at what point in your career you are, you don't need much imagination to adapt the recommendations to suit your experience.
Yazılım hayattına yeni atılacak arkadaşlar için her cümlesinde ayrı bir kaynak/teknik sunan bir kitap olmuş. Kitabın çoğu başlığı "Problem", "İçerik (bu problem ile nasıl karşılaşırız)" ve "Olası çözümler" şeklinde işlenmiş. Cevaplarda gerek duyulan başlıklara referanslar da girilmiş. Kitap içerisinde, sorunlara kitap önerileri de mevcut yalnız çoğunda kendinize uyan şekilde nasıl bu belirsizlikleri çözebileceğiniz ve aslında kendinize bu sorunların çözümü için nasıl alışkanlıklar edinmeniz gerektiği açıklanmış. Tek spoiler belirtmek gerekirse; Ne varsa eskide var :)
Excellent book that points you toward the road of software apprenticeship or life-long learning. It describes ways to become a better software craftsman and to manage your career. The book is divided into patterns with a problem for each pattern and solutions. Central to all or most of the patterns is that it is a road of learning and that once you have gained some sort of competency you should pay it forward.
Hugely valuable book if only a bit intimidating as it shows how much there is yet to learn even after years of education and work.