The Pragmatic Programmer: From Journeyman to Master
About This Book
Straight from the programming trenches, The Pragmatic Programmer cuts through the increasing specialization and technicalities of modern software development to examine the core process--taking a requirement and producing working, maintainable code that delights its users.
This book covers topics ranging from personal responsibility and career development to architectural techniques for keeping your code flexible and easy to adapt and reuse.
Read this book, and you'll learn how to
- Fight software rot;
- Avoid the trap of duplicating knowledge;
- Write flexible, dynamic, and adaptable code;
- Avoid programming by coincidence;
- Bullet-proof your code with contracts, assertions, and exceptions;
- Capture real requirements;
- Test ruthlessly and effectively;
- Delight your users;
- Build teams of pragmatic programmers; and
- Make your developments more precise with automation.
Written as a series of self-contained sections and filled with entertaining anecdotes, thoughtful examples, and interesting analogies, The Pragmatic Programmer illustrates the best practices and major pitfalls of many different aspects of software development. Whether you're a new coder, an experienced programmer, or a manager responsible for software projects, use these lessons daily, and you'll quickly see improvements in personal productivity, accuracy, and job satisfaction. You'll learn skills and develop habits and attitudes that form the foundation for long-term success in your career. You'll become a Pragmatic Programmer.
What others in the trenches say about The Pragmatic Programmer...
“The cool thing about this book is that it’s great for keeping the programming process fresh. The book helps you to continue to grow and clearly comes from people who have been there.”
—Kent Beck, author of Extreme Programming Explained: Embrace Change
“I found this book to be a great mix of solid advice and wonderful analogies!”
—Martin Fowler, author of Refactoring and UML Distilled
“I would buy a copy, read it twice, then tell all my colleagues to run out and grab a copy. This is a book I would never loan because I would worry about it being lost.”
—Kevin Ruland, Management Science, MSG-Logistics
“The wisdom and practical experience of the authors is obvious. The topics presented are relevant and useful.... By far its greatest strength for me has been the outstanding analogies—tracer bullets, broken windows, and the fabulous helicopter-based explanation of the need for orthogonality, especially in a crisis situation. I have little doubt that this book will eventually become an excellent source of useful information for journeymen programmers and expert mentors alike.”
—John Lakos, author of Large-Scale C++ Software Design
“This is the sort of book I will buy a dozen copies of when it comes out so I can give it to my clients.”
—Eric Vought, Software Engineer
“Most modern books on software development fail to cover the basics of what makes a great software developer, instead spending their time on syntax or technology where in reality the greatest leverage possible for any software team is in having talented developers who really know their craft well. An excellent book.”
—Pete McBreen, Independent Consultant
“Since reading this book, I have implemented many of the practical suggestions and tips it contains. Across the board, they have saved my company time and money while helping me get my job done quicker! This should be a desktop reference for everyone who works with code for a living.”
—Jared Richardson, Senior Software Developer, iRenaissance, Inc.
“I would like to see this issued to every new employee at my company....”
—Chris Cleeland, Senior Software Engineer, Object Computing, Inc.
“If I’m putting together a project, it’s the authors of this book that I want. . . . And failing that I’d settle for people who’ve read their book.”
—Ward Cunningham
Even when my contributions suck people think of it as a positive and often teach me the right to do the code or explain why the change is not necessary.
As far as books go I don't have anything to recommend. For me improving fundamentals was really about figuring out what I didn't understand and diving in to learn it. I prefer online materials over books but one book I have read that I thought was great is 'the pragmattic programmer'. https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...
Robert C. Martin, Clean code: https://www.amazon.com/Clean-Code-Handbook-Software-Craftsma...
Vaughn Vernon, various: https://www.amazon.com/Code-Complete-Practical-Handbook-Cons... 2
Clean coder: https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...
Hitchhiker's Guide to Python: https://www.amazon.com/Art-Readable-Code-Practical-Technique...
John Ousterhout, A Philosophy of Software Design: https://www.amazon.com/Philosophy-Software-Design-John-Ouste... This one looks particularly interesting, thanks AlexCoventry!
Kent Beck, Test Driven Development: https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/...
Dan Bader, Python Tricks: The Book: https://www.amazon.com/Software-Engineering-10th-Ian-Sommerv...
Svilen Dobrev, various: http://www.svilendobrev.com/rabota/
First read this blog post about UI design. A codebase is a UI. It is the UI you use to get your job done.
It seems to me that the problem is that you don't have a good mental model of the codebase and its pieces. Part of this is that the codebase could be better structured. It always can be. But part of the problem is that it takes deliberate effort to build a clear mental model. It is easy to spend a bunch of time fruitlessly poking at things if you don't know how to spend that effort. So What is the shape of that deliberate effort?
It depends on the framework. If you're working on a Model-View-Controller "CRUD" app, you want to start by looking at the API interface: what paths/HTTP methods do what? The reference docs for your external stakeholder should say this. Then, you'll want to look at the models. Print out the structure.sql or all the models.py files and draw out a crows foot diagram. From there, look at the controllers/routes and tell the story of what they do. Use the automated tests as a guide.
If you're not doing a CRUD app, you want to find some advice that is shaped like it. What files to read first? What diagrams are useful to draw? etc.
> I also take a lot of notes and write down what people say, seems to have been helping
This is a pointer toward a different approach you can take to solving your problem. Make yourself a set of indexed notes that you can refer back to, as if you were studying for an exam.
1) In the course of writing the email, you make your question more coherent and by doing that, you stand a good chance of realizing the answer.
2) By writing down the questions, you can structure them in a way that makes them easier to answer. Given that your questions are likely complex and can have multiple parts, this is pretty impactful. more on asking good questions
3) By writing down a coherent and contextful question, you show respect for the senior dev's time because you've put in your time to make your query well-structured.
4) You can go back and re-read the answer or the question. You can ask follow-up questions when you don't understand things. You can incorporate the answers into your set of notes.
Use a program like Anki to make flashcards about the framework. Make flashcards that ask questions about where things go and where you would put things. Also, make flashcards that ask you to explain why certain design decisions were made.
Find a good book to read and work through about the framework. Either ask on slack or ask your manager or go to the relevant subreddit. There is great value in personal recommendations.
Know that it is normal to still feel that you have lots to learn. This is a craft and you won't be done practicing it until you retire. For a broader look at the craft, take a look at The Pragmatic Programmer .
And of course make sure you are getting good sleep and taking care of your body.
To je čest anti-pattern, dovedu se fazani da održavaju stare projekte da bi stare iskusne kuke Pravile Novo. Keč je što su fazani po prirodi stvari nespremni za tako nešto. Zasuti nekoga ko je do tad radio samo na sintetičkim fakultetskim projektima gomilom real life legacyja je ... upitna praksa, ali nije ni skroz glupa pošto je to bitan deo realnog programerskog života. Kako kaže onaj kliše: "prvih 10 napisanih linija su greenfield projekat, sve preko je legacy kod". Sve što te ne ubije te jača. (F. Niče)
Ako nemaš živog mentora, ili ti je mentor go qrac, ovo je verovatno sledeći najbrži put do sledećeg nivoa: https://toptalkedbooks.com/amzn/020161622X
Knjiga jeste malo outdated po pitanju tehnologija, ali su principi i saveti odande svevremeni, dobri, i večiti.
There are two books I always recommend to anyone who is starting their Software Engineering career.
The Pragmatic Programmer: From Journeyman to Master
Clean Code: A Handbook of Agile Software Craftsmanship
Both of these books were recommended heavily to me when I joined the industry and I wish I would have read them sooner. They manage to boil down years of insight and experience into a couple of interesting and thought provoking reads. I always buy copies for my interns or college graduate level junior developers.
Also, don't be too embarrassed to ask questions of your co-workers. If someone makes a design decision and you don't know why, ask. Most developers don't mind answering questions if you frame it the right way. Always make it clear it's coming from a place of learning instead of a place where you are questioning their implementation and they will generally be happy to talk about it. The secret is, most developers love to talk about how smart they are. ;)
I would much rather have a junior developer working for me that is constantly inquisitive and shows they want to learn than a junior developer that says they can do something and a week later doesn't have anything to show for their time. Most developers I have worked with are reasonable and realize we all started not knowing how to do what we do. Not knowing something or being ignorant of something isn't a bad thing, we all have gaps in our knowledge. Being too stupid or proud to fix it though is a huge problem. You already recognize that there is a problem and are trying to fix it, that's half the battle right there.
Yes. Read The Pragmatic Programmer by Andrew Hunt. This will take you from "script kiddie" status to "engineer" status, and will change your mindset from "I can hack things together" to "I can engineer a solution." It's not hugely technical, but requires technical background to understand the context. I'd say it's a very appropriate guide on "how to think like a programmer."
I can't speak of a specific book that is a comprehensive history of computing, but I will speak to books that speak of our culture, our myths, and our hero's.
Hackers and Painters , by Paul Graham. People are polarized about the man, whether he's too "pie in the sky" - full of shit and ego, or if he speaks as an ambassador to our most optimistic ideals of our (comp-sci) culture. The contents of this book is a collection of his essays that are inspirational. It made me forego the societal pressures within our culture and reject popular opinion because it is merely popular and just an opinion, which is a virtue no matter who you are, where you are, or what you do. All these essays are on his website, though. If you want to review them, I recommend Hackers and Painters (the essay), What You Can't Say, Why Nerds are Unpopular, and The Age of the Essay; his oldest essays are at the bottom of the page and go up - he writes about what he's thinking about or working on at the time, so you'll see the subject matter change over time. So much of this will have direct application to his middle school and high school life. I cannot recommend this book, and the rest of his essays, enough.
If he wants to get into programming, I recommend The Pragmatic Programmer . This book talks about the software development process. I'm not going to lie, I don't know when best to introduce this book to him. It's not a hard read whatsoever, but it's abstract. I read it in college in my first months and said, "Ok," and put it down. Approaching the end of college and my first couple years in my profession, I would reread it ever 6 months. It's a kind of book that doesn't mean anything, really, without experience, without having to live it, when he has an obligation to his craft, his profession. I tell you about this one since you're asking about books to tell him, because this isn't something someone would normally come up across without being told about it.
The Cathedral and the Bazaar is a telling book about the cultural differences between the proprietary monoliths like Apple and Microsoft, and the Free and Open Source Software communities that back such popular software as Linux (the most popular operating system on the planet, running on all top 500 super computers, most server computers on the internet, and all Android phones) and Chrome(the worlds most popular web browser). Indeed, this book directly reflects the huge cultural battle that was duked out in the field, in the industry, and in the courts from the mid-90s and into the 2000s. It advocates helping the community, contributing to something larger than yourself, and that none of us are as good as all of us. To paraphrase Linus Torvalds(inventor of Linux) "Given enough eyeballs, all bugs are shallow."
It's important to know who the hero's are in our culture, and they are diverse and varied, they're not just computer scientists, but mathematicians, physicists, philosophers, science fiction writers, and more. I would find a good book on Nicola Tesla, since he invented basically everything anyway (Thomas Edison was a great businessman, but a bit of a tosser), Richard Feynman was a physicist who is still celebrated in his field, and he even worked for Thinking Machines, back in the day, which was a marvel of it's time. Seymour Cray founded Cray Supercomputers and they have a lasting legacy in the field, a biography on that would be interesting. A biography on Symbolics and their Lisp Machines will make him yearn to find one still functioning (a rare gem that crops up every now and again, though he can run one in an emulator), and about the "AI Winter", a significant historic era (note: the AI Winter is over, and we are in spring, the history is both compelling and enthralling). Anything Issac Asimov published (in nearly every category of the dewy decimal system) is also compelling, and hardly dated. In fact, he's the originator of a lot of modern sci-fi. Charles Babbage invented the modern computer (though it was entirely mechanical in his day, and it wasn't actually built until 1996-2002) and Ada Lovelace was the worlds first computer programmer. A woman! Speaking of women, and it's worth young men learning this about our history, Grace Hopper was a military computer engineer who invented the term "bug".
And speaking of women, someone I have respect for, especially if your boy wants to get into game development is Sheri Graner Ray's Gender Inclusive Game Design , which may be more appropriate when he's in high school, and I consider it required reading for anyone who wants to enter the gaming industry. The book lays out plainly how video games hyper-sexualize both women, and, for some reason surprisingly to many - men, it's disastrous effects it has for the game industry, the game market, and the gaming community, and insights on how we may combat it. I have seen colleagues (men) become indignant and personally offended at reading this book, but were absolutely humbled when they took the fight to Sheri directly (we had a few phone interviews with her, always fantastic). If your boy found a problem with this book, he would do well to read Paul Grahams essay on keeping his identity small... The subject matter is not a personal attack on the individual, but on the blight, and he would be better served finding himself on the right side of history with this one, it would serve him well if he were to pursue this craft, specifically, but also any forward facing media in general.
And I also recommend some good books on math. Algebra, linear algebra, calculus, and statistics. You can get very far, lead an entire career unto retirement without knowing anything more than arithmetic and basic, basic algebra, but he could only serve himself well if he makes the decision that he is going to like maths and chooses to willfully become good at it. Outside the context of school and terrible teachers, it's actually an enthralling subject. Just get him a copy of Flatland, Flatterland, and Sphereland. Try this , the book is the narrative of some witty laymen who discover a whole branch of mathematics from first principles, the surreal numbers, an extension of imaginary numbers. It's really quite good, but might keep him occupied for a couple years in high school.
I should stop here or I never will.
Don't give up just yet, keep looking. Do you have a portfolio? if not try to work on a project of your own so you can have something to show. And if you are considering improving your java skills try work with libraries like:
With spare time I would also recommend you to read:
* Code Complete https://www.amazon.com/Code-Complete-Practical-Handbook-Cons...
* Programming Pearls https://www.amazon.com/Programming-Pearls-2nd-Jon-Bentley/dp...
* Pragmatic Programmer https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...
This book seems to be a classic for programmers.