Show HN: Coding Career Handbook
learninpublic.org
learninpublic.org
I'm a little triggered by this headline. I understand what it means, and I agree there's some truth to it. It can be good advice when given to developers who haven't yet figured out that their job is not exclusively to write code.
But in my company (which is a big non-tech corporate) I've noticed that a similar phrase often gets used by non-technical people to belittle the work that software developers do. The exact wording varies, but the sentiment is basically that technical problems are easy, and can safely be outsourced to the lowest bidder, as long as there's a good Project Manager who can enforce the right methodology and processes. It's the problems that require "soft" skills that are difficult - these are the kind that Thought Leaders and Influencers work on - and we need to pay a premium for people who can solve these problems.
In reality, technical and non-technical problems are both difficult in their own ways, and both occupy a space that ranges from trivial to impossible.
In terms of career advice, I'd really suggest not perpetuating this myth. One of the tactics that the book lists is "marketing yourself", and repeating the idea that coding is easy (especially to non-technical people) undermines your career and that of your technical colleagues.
* maintenance is hard
* writing quality code is hard
* CI/CD is hard
* requirements gathering is hard
etc.
I like to hammer down on issues with contractors by basically minimizing the issue: "who cares if our customers couldn't access our product for 3 hours due to an outage? we're saving so much money by outsourcing!".
It's a simple way to get people on your side because noone would like to agree that 3 hours of outage is a good thing.
Of course you can't save money. The guy proposing the outsourcing is either getting kickbacks or will get a massive bonus from 'cost reduction'.
I like to kick the wind out of their sails by loving their proposal and reminding them that payroll changes don't count towards bonuses and they'll have to be up early to manage their new team. Suddenly, it's a bad idea.
- If you are working a company that has broken incentive structures, the first and immediate question you should answer for yourself is, what do you want to achieve there, as a manager? Are you really going to try and fix these deep cultural issues, and try to improve the company as a whole (or even just your department), and its whole internal mechanism for decision-making (which is broken and based on bad incentives)?
- If so, great! Commit to that problem, build support, get alignment, and who knows you might actually succeed, and end up in a C-level role for your efforts of turning the ship around. It's unlikely, but if that's your goal, then have at it.
- If not, then who cares? Accept the risks of what you signed up for, get whatever it is done that you need to do, and leave when the time is right. Understand your place in the hierarchy, understand what your personal goals are and how you can achieve them, and do whatever you need to do, without worrying about the health of the company or how other decisions are made. If you can't change it, or the effort to change it is out of the scope of what you're personally trying to achieve in your career goals, then it is literally a waste of time and energy.
---
On the topic of indicators or lack thereof, this is literally what good managers do. They find insights that others miss, and are successful in either making winning arguments or in framing debates differently and changing the success criteria. These powers can be used for "good" or "evil" to be blunt, that's up to the individual manager. You can practice at a small scale, for example for operational improvements by creating new metrics/KPIs for your team to better monitor service health in different ways than they used to. You can apply this to business decisions as well, by providing new analyses of how out-sourcing did not actually pay off, and defining new metrics for how to make those decisions (given that you've uncovered some hidden factors that were missed in the initial evaluation). There's no magic spell to it, it's just work and experience and critical thinking, which you gain through repeated application of curiosity and tenacity to problems that others tend to overlook or are too stuck in their ways to think differently about.
Personally, I loathe projects where I have little autonomy, and so I proactively seek out problems that other people don't want to own or have avoided owning or simply didn't understand or appreciate their important, but which I believe to be important problems (which depends on the prerequisite that, I actually must have some real insights which are unique that others have missed), and so I go out of my way to carve out ownership of those problems. Because nobody understood them before or wanted it before anyways, I don't get much pushback, and I can use these opportunities to make decisions autonomously, and also build up trust and support by demonstrating success with such projects. Eventually, I can leverage my banked trust store and positive balance of success, to push for changes or influence decisions in other areas that are more contentious and may not have gone "my way", had I not done the work to build up trust previously
The politics are the difficult part of most work in this industry. Everyone has an agenda (which is not a bad thing) and serving multiple agendas will make your technical problems even worse.
I've worked in just about every industry in my career, yet to find a place where those engineering specialisations are make-or-break, or even necessary.
The Coding will sometimes be the hardest part of a Coding Career.
Since people are throwing around authoritatively-sounding statements here, anyone interested is cordially invited to use mine.
The challenges in programming aren't literally "writing code", once you achieve a certain degree of facility with the language and libraries you are using.
The challenge is, of course, solving the problem - doing the intellectual work.
I get that people often say "writing code" and also mean the intellectual work of programming / CS / software engineering (whichever may be appropriate), but I really don't think that's accurate.
Hope that makes sense and isn't pressing too fine a point on it.
[edit] Rearranged some words for clarity
And he’s fresh enough that his advice isn’t enbittered and grizzled yet.
I quickly checked his writings. I am not trying to put him down, they are ok, but completely different than what I would expect an expert/authority to write. But seems nowadays 50+ tweets a day and 4 blog posts a day are more important than actually, you know, writing good maintainable code.
And this book is aimed at beginners, not folks like us with decades in the field.
But it doesn't matter if it is react or iOS or prolog. If you think about it, a CS degree, that covers a lot of topics, is minimum 3/4 years. And when you get out of uni you are considered an intern/junior. But now, bootcamps/web tutorials, people think that ater 2 years they become an authority on something.
I deal with these people everyday. They know 'react' inside out, but anything higher level (how to organize the freaking code) or how to use any kind of CS algo to solve a problem that isn't in the O(n^n) space because it is 'simple' is beyond them. Which is fine, is something that takes time to learn and know how to use. It took me years.
But 'I'm a senior developer' types with 2 years of experience is ridiculous, and we should call them what they are, liars. (not the GP, again, don't know him, talking in general)
(I don't think a CS degree is needed to be a software developer)
Who’s better for that advice? Someone who did it in 2 years or someone who took 10?
It matters because right now, we may have a coming recession where all these 'seniors' will see themselves fucked because companies will have more options and these 'seniors' will be too stuck up to realize they should be taking a more junior-ish position.
It also matters because I deal with these people all day, that because they read the latest blog post on something think they are experts and sidetrack 15 minute meetings to dribble on that we are doing it wrong and waste an hour of my time.
I've seen him go from someone who didn't know anything about web dev at all, to a master of what's going on with React and its ecosystem. He's added expertise on Svelte and other tools as well.
Shawn excels at a lot of "big picture analysis" type thinking (which makes sense given his prior financial background), and I always find his comments and presentations insightful and highly informative.
I haven't yet had time to read through this new book due to my own tasks, but based on the blog posts I've seen him write leading up to this, and the preview material he's tweeted, I have full confidence that this book is going to be an excellent resource for other developers.
As for the price, Shawn's clearly put a lot of time and effort into writing this. If you have questions about his ability to do so and the likely quality, I'd encourage you to read through some of his blog posts to get a sense of how he writes:
To me, it's not about the $40; it's about advice on "the full journey from Code Newbie to Senior Developer" from someone who is probably much closer to the former than the latter.
Stuff like reading books, training frequently, exposure to Machiavellian strategies, perennial interview practice, side projects etc is already known to most programmers who are aware and actively seeking improvement.
One thing that I like to see most programmers pay importance to in the future is physical fitness and rest. Mental health would also be a good topic to add. We are a profession where every one wants to win spectacularly or die trying. Or we just over eat and sit our excercise-less bodies to death.
A comprehensive programmer nerd's guide to exercise, rest and mental health would be something I'd be interested in reading.
I basically deal with it by being super open about it (it's pretty much the first thing anyone knows about me) and letting people decide if they still want to read me or not. enough do. in a free market, that's plenty.
so the question then becomes: what confidence do I have in what I think I know? it comes from 3 places:
- Empirical foundation: study and read others. this book has 1419 external links and quotes to advice from people way more credible and established than me. I provide curation and context.
- Theoretical foundation: I do my best to ensure what i see in real life is backed up by indisputable logical/psychological axioms. This is important for replicability.
- Personal Experience: I apply what I learn to myself.
Every weakness can be a strength (funny enough, i spend a whole chapter talking about this). In my case, i've basically made a career out of putting out what i learn as i learn it, before i'm an expert, with the responsible disclaimer that I am not an expert but I do put a ton of work into thinking and research. it's the opposite of "fake it til you make it", its being real that you havent made it yet but you do not let that stop you trying. I am at the exact point where my voice and perspective on things (being a recent beginner) let me explain things to beginners in ways that experts can't.
Yes it's uncomfortable af. But you see tremendous growth when you are both intellectually honest and doggedly persistent at this.
As I wrote this book I was also overcome with this personal insight - me 5 years from now would probably not pick this book to write. I would be interested in different things, different challenges. This is pretty much the only time I would ever write a junior-dev-to-senior-dev book: right after having done it.
I suspect this is why so few junior-dev-to-senior-dev books exist - people wait too long, and then by the time they feel qualified to write a book, they care more about management or architecture or what have you.
short answer: no i don't feel very qualified right now. i do intend to update this for a few years. how long until i am qualified? we shall see.
EDIT: I would like to note that the IMHO most mentally and technically difficult part of a developer career is maintaining the same mission-critical legacy codebase for years at a time. That's not something I really expect to get a lot of insight around from this book and your personal experience, but I'm also not sure what exactly advice around that problem would look like (probably just the tried-and-true military motto of "embrace the suck"). Either way, just my 2 cents about coding careers.
agreed on the maintaining legacy bit. I spent some time on that in the sr dev chapter, but it was mostly collating what others have said. i think its impt that jr devs be aware this is a big part of the job, and also that "technical debt" often pays incredibly well because it is so challenging and the skillset to handle it well is so rare.
I still have the feeling that there is a bit of greed here, trying to find shortcuts, this is not blatantly wrong but I have the intuition that this is a potentially harmful mindset, not unlike the Move Fast and Break Things mindset.
Write a book for Packt on X you are learning as you go => Leading expert in X and charge 100USD/hour
Write a bunch of blog spam on X, a lot of it wrong => Leading expert in X and charge 100USD/hour
Create a bunch of projects that have more bugs than Swiss cheese has holes => Leading expert in X and charge 100USD/hour
There is a story today here that says GitHub is the Instagram of programming, and more and more I agree. Technical knowledge has been trumped by marketing. You are only someone if you have a blog/github profile/stackoverflow with more than 1M+ points.
And then people wonder why software is so shitty now days, why a todo list in React makes any laptop run out of battery in 50 minutes (not attacking React, just how beginners use it).
There is so much cargo culting nowadays in software development (agile, GitHub, white board interviews, hacker rank, tdd, add, ci, cd, redux, etc etc) and so many new people (< 5 years) without experience to see what works and doesn't work with the team and project that is hard to fight it.
I worked in 3 different React projects in the last 2 years with 3 different teams. Only one required something as complex as Redux (and most likely Flux or other simpler state libraries would do). You know what? All of them had redux. It is what they learned in the latest blog post by ReactHipsterMainMain.com so that is what you see.
If you are 25/28 years old and a start up CTO (?!?) and you spent your 20s in university and doing open source code and putting shit in GitHub, you value that and try to hire for that. Thus, this is well known and bootcamps and the likes teach people to put every little shit in GitHub to show they are 'passionate' about software development and has done a lot of projects.
Even the take home projects. From experience, most companies have the same variation of the project. For iOS this is usually show a screen with data from an API, tap something and show details, also from an API. You can find millions of these small projects all over GitHub. But somehow they still ask for them. A few years ago I was so tired of this that I created a generic project and then a script that would take a JSON file and would generate the Swift Models, as well as API calls->transform to Model, and I would just need to create 2-3 functions to configure each cell depending on the data. I haven't seen any junior developers do something like this in their jobs. There are more and more classes, view controllers, components, stores etc. The abstraction thinking just isn't there yet. But they act like they know everything and have all the answers because of GitHub stars or whatever they are called.
I am all over the place with this reply, I am sorry. Just after years and years of seeing this, more and more I don't think soft development is for me if it is just to become the Instagram of the geeks.
https://redux.js.org/faq/general#when-should-i-use-redux
https://medium.com/@dan_abramov/you-might-not-need-redux-be4...
Unfortunately it falls on deaf ears and it is still overused pretty much everywhere.
Well, absolutely nothing, and it's a shame to see people (I have to imagine mostly college interns and fresh grads who already fancy themselves as "mid-level" developers) waste money on this nonsense.
Unfortunately this is what happens when you see job advertisements requiring "Senior Developers" and specifying 5 years of total work experience. In no other industry can you be a 27 year old and be anything other than junior-to-mid. I say this as someone who was a senior developer in my late 20's, and you don't know anything in your late 20's.
But I suppose if you're a senior developer after a couple years, what's to say you can't advise people on their careers when you haven't even made it through a Presidential election?
Now the question is, investing those few days total saves you more worries. And doesn't derail you. That's hard to evaluate, and I don't attempt to. But for information, $40 is cheap.
I'm frustrated and saddened by the amount of negative comments here from doubters, burnt out folks, and cynical engineers. I want to weigh in with a positive perspective.
I've been following Shawn for a while now (from a distance) and I have to say, seeing his name pop up in more and more places has certainly been an intriguing experience. He went from being nobody a few years ago to being somebody worth listening to very quickly.
He's built up a lot of good will with me just from what he's posted that is freely available, so it's a little frustrating to see other people bashing / looking for problems as soon as he releases something with a price tag. I personally have benefited a lot from his "learn in public" approach (more from his example than from his advice!!) and have had multiple posts hit the front page of HN by "learning in public", from which I've learned further (it's a positive feedback loop).
Full discloser, I haven't read this book, but the interesting thing is that he's only recently started monetizing this exposure. That rings true to me of somebody who knows what they're doing and has real value to bring to the table.
For people who are saying "But he doesn't have enough experience," bear in mind that this book has ~1400 references to other peoples' experience. I trust that way more than I do one person's singular viewpoint, even if that is backed up by 40 years' worth of experience.
Also, before anybody tries to call me out – this is a 100% spontaneous response and I had no idea Shawn's book was out until I saw this post on the front page of HN.
I'd be more interested in the insight someone like Fabrice Bellard gained during his coding career, especially if we're talking about productivity or impact.
Since I switched careers from finance and started doing freeCodeCamp in 2017, I have been studying the principles, strategies, and tactics that make great developers successful and applying it to my own career. This has helped me get hired at a Senior level at AWS in just 3 years. While between jobs, I decided to take the time to write down everything I've learned about the tech industry - everything I wish I had known, everything I believe to be true, everything I think an individual contributor developer needs to build an exceptional career:
- Going from Junior to Senior
- Learning in Public
- Tech Strategy (the Business of Software)
- Why You Should Write (A Lot!)
- Engineering Career Ladders
- Developer's Guide to Twitter
- Marketing Yourself (without Being a Celebrity)
- and more!
Roughly 1/4 of the chapters are prior blogposts that have done super well - my greatest hits include https://www.swyx.io/writing/learn-in-public/ and https://www.swyx.io/writing/marketing-yourself/ - and since publishing them I have loads of feedback and rewritten them for the book. The remaining 3/4 are brand new content I have applied for my own career, and market tested the messaging in tweets, talks and podcasts.
There's a launch discount applied to everything on the site; I hope you enjoy it!
---
Side note on tech stack - For the book, I am using https://softcover.io which is a Rails app that Michael Hartl uses to create the Rails tutorial. It's the best tool I found that generates PDF/EPUB/MOBI out of the box with decent customization by exposing LaTeX (and its also FOSS, with a paid option!). For my site I am using Begin.com for hosting and functions, Svelte for components, and Podia for payments. For Audiobook I am using Audacity and my trusty standard issue Egghead.io Instructor Shure mic! Putting this together was a good couple weeks of trial and error - Let me know if I can answer any tech stack questions alongside book questions!
Did you also consider leanpub?
here's the long form story - https://medium.com/hackernoon/no-zero-days-my-path-from-code... - ive been harangued over this before so i should be clear that i have done programming prior to starting FCC - just that it was basic self taught data munging stuff, not web dev. i definitely did not start from zero, but i also definitely felt very out of my depth learning the JS/Web stack in 2017 and it took me a year to get to the point where I could credibly apply for a frontend dev job.
thanks!
theres the added complication that i'm stuck here in Singapore due to coronavirus, whereas my target audience is all in the US. so i probably shouldnt do shipping myself.
I'm glad to hear more people are using it.
That said, Shawn has been writing this book in public, so anyone who's been following him does know that he was about to launch.
They spend their whole time selling shovels.
Distills much of the best advice you can get if you hang out for a few years on HN into an easily shareable package.
Would recommend as a graduation gift or career starter for the new tech person in your life. But also super valuable for folks who have been in the industry as well. The chapter on "Marketing Yourself" contains some reminders that I found really helpful:
- Keep online presence 90% positive
- Be consistent (same profile pic everywhere, etc)
- Be "The Guy" (or non-guy) for a specific, unique, easily-grasped value prop
- Don't chase celebrity or short-term optimizations (posting times, weekly metrics, etc)
edit: for those who don't know - forrest does a Cloud Resume Challenge where he helps people get started with a career in the cloud - laying out exact steps and offering his personal network to anyone* who completes them: https://forrestbrazeal.com/2020/04/23/the-cloud-resume-chall...
*he has 2 conditions, listed on the blogpost
I mean, kudos to him certainly; who you know is more important than what you know to getting seen and heard. This is a great leg up for the right people.
(I’m sure it’s mentioned in the book, but I couldn’t help but ask anyway :])
I think of Corey Quinn, whose pitch is "I fix your AWS bill." Short, easily-grasped, specific.
this is obliquely referenced in the book, but i believe the most effective pitch is if you can losslessly compress your entire value proposition into two words. https://www.swyx.io/writing/two-words/
Corey invented "Cloud Economist" for this purpose. brilliant. no one can compete in a category you invented.
I've argued that in some ways a more effective positioning statement would have been "I fix the horrifying AWS bill for SaaS companies in the Pacific Northwest" or whatnot; you want your prospective clients to see themselves in what you do.
Fortunately, "the AWS bill" is painful enough of a problem without too many other viable alternatives that this was "enough."
easily-grasped (value prop)
not
(easily-grasped value) prop
It would be better to link directly to that page I think.
I've been a professional dev for over ten years and I have a CompSci degree from a respected university. I'm getting paid principal engineering salary for a moderate sized city in the U.S. and I work remotely from Canada in a fairly cheap cost-of-living city at a small company (far from Silicon Valley salary, but pretty damn high for here).
Do you think this book will be useful to me? I want to maintain my career as a developer and grow in skill and salary. I have started blogging about a year ago and I do infrequently but I think my posts are decent. I also am taking the time to learn some stuff like ML and am constantly trying to improve my skills with stuff like PostgreSQL and Go.
Good luck! I am certainly always on the side of developers working on themselves.
Unfortunately this book seems too all-over-the-map to be particularly useful to where I'm at in my own coding career: about 18 months into it.
There are two pieces to this book if I read the marketing pages correctly: * First, the overplayed trope of "How to get hired as a Pr0gRaMmar!!!1" -- a cottage industry nearly as large as the field of engineering itself * Second, the less-played trope of, "Here are some actionable ways to develop your career path under the severe time constraints that an engineering career will present you with"
If this text were more exclusively drilled down into the second topic rather than the first, I'd probably make the purchase.
However, I don't feel like spending time reading through a lot of things that I either already know, or that don't apply to me.
The usage of "coding" with respect to the job often comes off as a polemic against those other facets. Sometimes this is what you want! Maybe you're breaking free of all that architecture astronomy and faux-agile BS to just build stuff. Maybe you're differentiating yourself from your senior colleagues who seem to write only documents. Maybe you want to hire someone to shut up and type, not pester you about tech debt. But these are all fighting words.
It gets old when people pick up this usage and repeat it without even meaning it.
[0]: https://treetide.com/book/programming-without-anxiety.html
So every product starts as high as possible to discover the price. Because there will be time to lower it.
(Increasing the price afterwards never works, because early adopters are more elastic)
This book isn't trying to sell itself by saying "hey, buy me and you'll be entertained for three hours, which is a better value than a movie ticket".
This book is trying to convince potential customers that it will help them graduate from junior engineer at local_company to senior engineer at FAANG. It's no coincidence that the author mentioned right here in his opening post that he landed a senior role at AWS. (I realize that's not a dream for many, and the whole FAANG thing is aggravating, but enough people think this way.)
If you (as a potential customer) aren't convinced, then you have no reason to buy this book even for $10.
On the other hand, if you are convinced, then the upside is so large that this book is worth buying even for $500.
Not many people will be on the edge pondering "I really think this book could help me triple my salary and status but that's worth $10 to me, not $40".
Great book for people that are just starting their coding career but also for those with a good bit of experience. If you're feeling 'stuck', this is a great guide to understand how to advance your career.
'Learn in public' is probably the #1 piece of advice I'd give to anyone in tech. It helps your writing, it builds your network, and it grinds down your ego (because people will certainly let you know when you're wrong). Swyx has been a huge proponent of this, and this whole book is a great kick in the pants to get started.
I'd be shocked if this book doesn't make you >>>10x the amount you spend on it (even counting a healthy hourly rate for reading it).