I've been a developer for around 10 years now and still feel very lacking on a technical level, mostly due to bad choice in companies where most of the problems are of the organizational kind (processes, teams, incompetent people).<p>Even though I am quite unsure of my actual expertise I want to start contracting, but not as just another developer.
I want to add value by improving development processes, cutting crap from the lifecycle where possible, and optimize on a more organizational level.<p>So far I have bought a few technical books and am looking out for some more non-technical ones:
* Pragmatic Programmer
* Clean Architecture
* Designing Data-Intensive Applications
* Accelerate<p>What else would help me in finding help to be more than just another developer / contractor?
Trust as a contractor can be an interesting thing. On one hand they may not trust you because you are an outsider who they think can't possibly understand the nuances of their culture and business domain, but on the other hand they will often deliberately trust you on technical matters because you are bringing outside perspective. Point being - you may get more of the opportunities you want by virtue of being a contractor.<p>That said - I'm not completely sure what you are really after here. When you talk about wanting to be something more - like what? You want to be an architect? You want to be in management? You want to be a subject matter expert? Product management? I wonder if either a startup or a large corp would be good for you... what I mean is, let's say you are early at a startup. Well, you get to do a bunch of everything because there's no one else to do it. Alternatively, big corps can be a great place to spend a year in this team, a year in that team, and give people lots of experiences in one place, where each role builds on the next - assuming you are managing your career and don't get stuck somewhere. Not sure what's the right option for you, but I'm assuming you'll run with this and figure it out.
I recommend personal productivity books, especially Getting Things Done by David Allen. Everyone in the department needs to read and follow the principles, which can be very hard to sell when you are not the boss yourself. The worst thing is being in meetings where people agree to pieces of work, then a week later at the next meeting, nobody has done anything, they all have excuses but the real reason is they didn't write it down, didn't take responsibility to understand what the whole team and project needs from them, and they don't get any pressure from management to do a better job than that. I eventually gave up trying to "fix other people," and instead just implemented my own system so at least I could be 100% responsible for doing my own tasks and project pieces that I agree to do. You can set a good example - but it's rare that anyone will follow your example without pressure from above. You'll even get kudos from the people who can't do it; then after that - they make no progress themselves personally. The gears don't engage. Honestly it's very frustrating. Every job I've had over the past 35 years except one were dysfunctional organizationally, and nothing I did as an individual contributor had much impact.
Learning about personality traits and how to connect with different types of people, can be very useful in becoming better at communicating with others on a team, your boss, different types of managers in different roles, etc.<p>Learning sales strategies and principles is way more useful than it sounds like it would be. Engineers don't want to hear this, but all individual contributors have to sell, at one time or another: you sell your ideas and approaches to solving problems (so the boss/team will understand and agree to your ideas), because you want the right thing to happen with the project you're working on.
You sell yourself when interviewing for jobs. Sales techniques even help with dating, to help you understand what wrong things people sometimes say, and how to say things in better ways that have the same meaning. Learning more about selling would have come in very handy earlier in my sw dev career. It also sets you up better if you ever decide to branch out on your own and start a business of any kind. Selling has a lot of technical details to it, more than you would think. It's not just simple and 1-dimensional and thus ignorable, like I imagined when I was getting my CS degree so long ago.
I know its a tired and overused suggestion - but if you can potentially join an early stage company (early stage as in: you are one of the first three or four devs), you'll get the opportunity to see which processes work and which do not, as well as observing (and participating!) in the growth/scaling of an engineering team.<p>Technical skills are great! However, I've honestly learned some of the more advanced topics on the job. For example, I had sort of a hand-wavey understanding of distributed services/architecture, but I only became intimately familiar with it once I was asked to design one at a very small company.<p>TL:DR; books are great. Read them. They do not replace the learnings that come from "hey showsover, uh, can you try and figure this out for us?"
Test-Driven Development by Example, Kent Beck.<p>If I could describe it in a sentence, it's for people who would procrastinate because they're not sure what to do next.<p>There's a lot of philosophical differences from "modern" TDD. It's not about test coverage. In fact, Kent doesn't encourage doing the obvious.<p>It's using the tests to reduce cognitive load. You think about how it actually works before writing code. If you get stuck, you can do something like write a constant in the code to make the test pass, then convert that constant into an expression. If you're still stuck, write some more tests, then triangulate those into an expression that passes the tests.<p>It turns anxiety from this anxiety inducing, 4-hour flow requirement, into this sudoku puzzle. If you like the flow sessions, by all means, go with that, but it's an extra tool for when you don't have the energy or blocks of time.
Based on my professional experience:<p>"Building Microservices: Designing Fine-Grained Systems", useful when working in orgs using microservices. This is not only technical and it will make you appreciate "Domain Driven Design", already recommended in this thread.<p>How to win friends and influence people, must read if you intend to deal with people in your career.
In addition to those technical books, I'd check out:<p>* Staff Engineer- Great for the tech challenges beyond senior-level <a href="https://staffeng.com/book" rel="nofollow">https://staffeng.com/book</a><p>* The Manager's Path- Good even if you're not going to be a manager. Understanding their perspective makes you more effective <a href="https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897" rel="nofollow">https://www.amazon.com/Managers-Path-Leaders-Navigating-Grow...</a><p>* An Elegant Puzzle- What if distributed systems engineering, but with people? <a href="https://lethain.com/elegant-puzzle/" rel="nofollow">https://lethain.com/elegant-puzzle/</a>
I found this book sometime ago and it looks very interesting.
<a href="https://mitpress.mit.edu/sites/default/files/sicp/full-text/book/book.html" rel="nofollow">https://mitpress.mit.edu/sites/default/files/sicp/full-text/...</a>