And just because it’s asked at every interview.
I’m focused on AWS these days, but a lot of these principals are universal.
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://vaughnvernon.co/?page_id=168
Steve McConnell, Code Complete: https://www.amazon.com/Code-Complete-Practical-Handbook-Cons... 2
Clean coder: https://cleancoders.com/ videos
Hunt and Thomas, The Pragmatic Programmer: https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...
Hitchhiker's Guide to Python: https://docs.python-guide.org/
Dustin Boswell The Art of Readable Code: 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://dbader.org/
Ian Sommerville, Software Engineering: https://www.amazon.com/Software-Engineering-10th-Ian-Sommerv...
Svilen Dobrev, various: http://www.svilendobrev.com/rabota/
Clean Code: A Handbook of Agile Software Craftsmanship
This book really helped me focus on code organization and seeing maintainable code as an overall goal whilst building long-term applications. I'd say that one of the reasons why the work I've done 3-4 years ago can still be used, expanded, and maintained today is because of this book. Short functions, code organization, and naming conventions all stuck with me.
I'd say that unlike other programming books, this one focuses on the "art" and "organization" rather than syntax and other aspects of programming.
The Pragmatic Programmer: From Journeyman to Master
This book tackled real-world application building and practices. I'm still reading it. I liked how it tackled not only some basics of programming (resource management practices) but also project management to a certain extent. Eg. how to use prototypes, how to use "trace bullet" programs, etc.
Game Programming Patterns
I think one of my favorites has been "Game Programming Patterns" http://gameprogrammingpatterns.com/ which is free online or you can get an ebook/print version http://amzn.to/2veRdiO
The book introduces several basic design patterns, it explains WHY they're used, how to implement them, etc. in the best way I've read so far. No CS book or online article has been able to explain these patterns as this book did.
And I'm not even a game developer.
Also, check out this post on dev.to -- https://dev.to/ben/what-are-the-most-interesting-readable-so... it has some good answers! :)
"Working Effectively with Legacy Code"^1 is usually what I recommend instead. It felt like a more up to date approach
More generally "The Pragmatic Programmer"^2 is a classic for a reason. But from you're comment you've probably already read it.
* 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.
A Pattern Language, Alexander and Ishikawa and Silverstein http://amzn.to/2s9aSSc
Advanced Programming in the Unix Environment , Stevens http://amzn.to/2qPOMjN
Algorithmics: the Spirit of Computing, Harel http://amzn.to/2rW5FNS
Applied Crytography, Wiley http://amzn.to/2rsULxS
Clean Code, Martin http://amzn.to/2sIOWtQ
Clean Coder, Martin http://amzn.to/2rWgbEP
Code Complete, McConnel http://amzn.to/2qSUIwE
Code: The Hidden Language of Computer Hardware and Software, Petzold http://amzn.to/2rWfR9d
Coders at Work, Seibel http://amzn.to/2qPCasZ
Compilers: Principles, Techniques, & Tools, Aho http://amzn.to/2rCSUVA
Computer Systems: A Programmer's Perspective, O'Hallaron and Bryant http://amzn.to/2qPY5jH
Data Flow Analysis: Theory and Practice, Khedker http://amzn.to/2qTnSvr
Dependency Injection in .NET, Seemann http://amzn.to/2rCz0tV
Domain Driven Design, Evans http://amzn.to/2sIGM4N
Fundamentals of Wireless Communication, Tse and Viswanath http://amzn.to/2rCTmTM
Genetic Programming: An Intrduction, Banzhaf http://amzn.to/2s9sdut
Head First Design Patterns, O'Reilly http://amzn.to/2rCISUB
Implementing Domain-Driven Design, Vernon http://amzn.to/2qQ2G5u
Intrduction to Algorithms, CLRS http://amzn.to/2qXmSBU
Introduction to General Systems Thinking, Weinberg http://amzn.to/2qTuGJw
Joy of Clojure, Fogus and Houser http://amzn.to/2qPL4qr
Let over Lambda, Hoyte http://amzn.to/2rWljcp
Operating Systems: Design and Implementation, Tanenbaum http://amzn.to/2rKudsw
Parsing Techniques, Grune and Jacobs http://amzn.to/2rKNXfn
Peopleware: Productive Projects and Teams, DeMarco and Lister http://amzn.to/2qTu86F
Programming Pearls, Bentley http://amzn.to/2sIRPe9
Software Process Design: Out of the Tar Pit, McGraw-Hill http://amzn.to/2rVX0v0
Software Runaways, Glass http://amzn.to/2qT2mHn
Sorting and Searching, Knuth http://amzn.to/2qQ4NWQ
Structure and Interpretation of Computer Programs, Abelson and Sussman http://amzn.to/2qTflsk
The Art of Unit Testing, Manning http://amzn.to/2rsERDu
The Art of Unix Programming, ESR http://amzn.to/2sIAXUZ
The Design of Design: Essays from a Computer Scientist, Brooks http://amzn.to/2rsPjev
The Effective Engineer, Lau http://amzn.to/2s9fY0X
The Elements of Style, Strunk and White http://amzn.to/2svB3Qz
The Healthy Programmer, Kutner http://amzn.to/2qQ2MtQ
The Linux Programming Interface, Kerrisk http://amzn.to/2rsF8Xi
The Mythical Man-Month, Brooks http://amzn.to/2rt0dAR
The Practice of Programming, Kernighan and Pike http://amzn.to/2qTje0C
The Pragmatic Programmer, Hunt and Thomas http://amzn.to/2s9dlvS
The Psychology of Computer Programming, Weinberg http://amzn.to/2rsPypy
Transaction Processing: Concepts and Techniques, Gray and Reuter http://amzn.to/
Types and Programming Languages, Pierce http://amzn.to/2qT2d6G
Understanding MySQL Internals, Pachev http://amzn.to/2svXuFo
Working Effectively with Legacy Code, Feathers http://amzn.to/2sIr09R
Zen of graphics programming, Abrash http://amzn.to/2rKIW6Q
- There is no "silver bullet" for managing the complexity of user needs. Instead, (good) software is characterized by not a static state of "solving the problem", but a continuous refinement-- an existential struggle against incidental complexity.
- Have a very positive mindset, and inspire the same in your team.
- highly reliable websites for small companies: http://www.kalzumeus.com/2010/04/20/building-highly-reliable...
- Learn your debugging tools well: Get good at Chrome Debugging tools, pdb, visual studios debugger, or whatever the debugging environment is for your project.
- “… never consider your education complete or your opinion above questioning regardless of your title, your years of experience, your awards and accomplishments, or anything else that isn’t rational argumentation or evidence. Retaining a healthy degree of humility, constantly striving for improvement, and valuing objective metrics above subjective considerations will go a long way ..."
- This is a marathon, not a sprint.
- Practical engineering advice: https://www.quora.com/What-are-the-best-kept-secrets-of-grea...
- Read books. I can especially recommend Refactoring by Martin Fowler and The Pragmatic Programmer as a more introductory text (affiliate links: http://amzn.to/2ekPnTL and http://amzn.to/2ekJQMK). Understanding why and how to do scrum effectively is really important too -- I waited too long to read a book that laid that out for me (http://amzn.to/2ekPxul)
- Good programming advice from Kent Beck: https://www.facebook.com/notes/kent-beck/mastering-programmi...
- Eventually, you will have to choose between engineering management and continuing to be close to technology. Trying to do both is a recipe for burnout. Some people might be able to do both simultaneously without trouble, but you're probably not one of them.
- Always be looking for ways to remove yourself as a bottleneck. This needs to be done both on a technical level and on an organizational level.
- Push back as necessary against demands of your time and energy that are not in harmony with your needs as a technologist.
- Good programming comes from good habits. (in that vein: copy-and-paste is the devil.)
- Seriously, read books. It's incredible how much good advice is out there.
* High Output Management by Andy Grove https://www.amazon.com/gp/product/0679762884/
* Turn the Ship Around by David Marquet https://www.amazon.com/gp/product/1591846404/
* The Score Takes Care of Itself by Bill Walsh https://www.amazon.com/gp/product/1591843472/
For interns I give out these two books:
* The Pragmatic Programmer https://www.amazon.com/Pragmatic-Programmer-Journeyman-Maste...
* The Passionate Programmer https://pragprog.com/book/cfcar2/the-passionate-programmer
Unfortunately it looks like you have to watch the video in order to find out what the practices and details are.
Unless you've been seriously programming for a number of years, with a fair amount of that in teams, including face to face ones, you're probably not nearing your peak. I'd suggest reading The Pragmatic Programmer: From Journeyman to Master (http://www.amazon.com/The-Pragmatic-Programmer-Journeyman-Ma...) and judge where you are in the range from journeyman to master.
If you're looking for "lock-in", i.e. be easily employable past your ability to fake looking under 35, I'd suggest getting a job with a serious security clearance, which can be a trick, or specialize in one of the fields that respects grey hairs like embedded (but only so much depending on the sub-field, e.g. Detroit car companies at least in times past recruited heavily from Course 6 because they too got rid of their older EEs and programmers).
If you goal is to really work for yourself, and you think you can eventually bill at a rate 5-6 times the income you want to receive---maybe talk to some professors who make a lot of money on their one day a week dedicated to that, albeit they do it with MIT Professor on the CV---yes, that's a very good way to go. But hard for most people. See e.g. this comment https://news.ycombinator.com/item?id=9499561 which points out you have to compete on quality, not price, and a couple of HN contributors who've written a lot about that.
Medicine: in a county, or the developed "West", where people by and large don't directly pay for their own medical care, and those who do pay are looking at a rapidly graying population, well, it's a field you ought to run screaming from, unless it's your calling.
Don't know about MechE and so on, in general you need to talk to older engineers, the people who run the department, professors, etc., of course adjusting for selection bias. If you haven't already identified a calling, well, you have a lot of options, especially if you're strong at math. Especially before the 2008 crash, a lot of EE strong and therefore math strong EECS graduates would get initial jobs in finance with their proven math chops, which if they were smart got them in a good financial position to do something they really wanted to do later.
My go to recommendations:
http://www.amazon.com/Structure-Scientific-Revolutions-50th-... - The Structure of Scientific Revolutions, Thomas Kuhn, (1996)
http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master... - The Pragmatic Programmer, Andrew Hunt and David Thomas (1999)
Things I've liked in the last 6 months:
http://www.amazon.com/How-Measure-Anything-Intangibles-Busin... - How to Measure Anything, Douglas Hubbard (2007)
http://www.amazon.com/Mythical-Man-Month-Software-Engineerin... - Mythical Man Month: Essays in Software Engineering, Frederick Brooks Jr. (1975, but get the 1995 version)
http://www.amazon.com/Good-Great-Some-Companies-Others/dp/00... - Good To Great, Jim Collins (2001)
Next on my reading list (and I'm really excited about it):
http://www.amazon.com/Best-Interface-No-brilliant-technology... - The Best Interface is No Interface, Golden Krishna (2015)
I also sent the following as advice to someone wanting to get into web dev:
"I was just thinking of 'easy ins' to the world of web development and a good source of information is http://news.ycombinator.com/ there's a lot of information from people who work in the world of tech startups and it's good information.
Also - if you are wanting to do php dev the key things to learn are:
Software engineering techniques and practice - object oriented development and abstract patterns are key to how to think about good development.
Database design and development (1st normal form, third normal form etc) Learn SQL. (SQL for dummies or similar is good for the basic commands and syntax etc.)
Stackoverflow.com - it's the best source of help for software development on the internet.
read books, the ones that come up again and again when people talk about learning to program:
also - look at github.com - that's where programmers keep their source code.
Learn about Object Oriented Programming, Design Patterns, MVC (which is a design pattern) is specifcally useful for web development.
That's my starter for ten - if you are interested in a career as a web programmer.
If you want to focus more on the html/css design side you could do worse than focusing on one CMS - such as wordpress and learning it inside out - you could then offer that to clients and it's a good way to provide web sites cheaply with very little effort."
This blog post doesn't express things nearly so well as the book, but the argument has validity.
2. Pragmatic Programmer: http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master...
Fresh book recommendations delivered straight to your inbox every Thursday.