> The Coding will always be the easiest part of a Coding Career
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.
To be honest, the technical problems are the easy thing in most companies since they just need a simple CRUD app and anything you do will be magic to most people regardless.
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.
Depends where you work, if it's a dinky ecommerce site with no scalability issues, then coding is not a problem. But if it's a real product company with AI/ML engineering problems, then coding definitely is.
> a real product company with AI/ML engineering problems
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.
Same. Most product startups I've worked on where the business model seemed to be working, always the stability and scalability of the platform are the main problems.
Just because something (a simple CRUD app) seems simple to you, doesn't mean it'll be easy for everyone, in particular if you don't know what the quick ways are of doing it.
Coding isn't the hard part of your job, it's convincing people that outsourcing isn't going to result in good outcomes. The reason why they won't result in good outcomes:
How much success have you had? Not trying to be snarky - but the problem in corporates is there are no "lag indicators" of success. The success of a manager is defined as getting to a specific cost structure, there is no measure if that cost structure delivers the results. And in a lot of big corporations what's good for your career and what's good for the company may not be the same thing.
Corporations won't stop outsourcing because of reason, but they will stop outsourcing because of feelings.
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.
But in my experience I have never seen cases where you really save money. The outsourced dev charges less, yes, but the outsourcing company needs to make money. But let's say what was 10 an hour, now it is 5. In my experience is that what used to take 1 hour, now it takes 2 or even 3. In the end, hardly any savings.
> I have never seen cases where you really save money
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.
There are different strategies you would use for dealing with different companies, especially for companies with very deeply broken incentives or broken feedback loops (no company is perfect, but many function reasonably well, and some function not at all). You can't fix a broken process for decision-making, by making a few isolated good decisions; you have to attack/fix the broken process itself, if you ever really hope to make an impact.
- 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
I dunno. Coding is the easiest part of programming, in a sense.
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.
Please don't take this the wrong way; I am genuinely curious. As far as I can tell, you've been a professional developer for approximately 2 years. What qualifies you to instruct people how to manage their dev career, let alone charge $40+ for the advice?
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.
For Github projects, we could have an organization that would conduct project audit and certification on owner's expense. As an owner of a few open-source projects, I'm a little tired of hearing such insinuations as in the post above (although there is certainly a grain of truth in it -- we live in the Age of Bullshit, after all), so I would gladly cash out $1000 for getting a "quality approved" stamp from a widely trusted entity.
i think its a fair question and you've been very polite about it :)
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.
Thanks for clarifying. I think I will give it a read, even if just to see what your fresh perspective looks like. The personal branding stuff sounds very interesting and useful also.
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.
thank you for having an open mind, and also being willing to say what others are already thinking, but doing it nicely :)
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.
All of this seems kinda legit, learning and be open and using both your experiences and your interactions with others to fix or reinforce your assumptions, but this is not what people usually expect to find in a book...
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.
Haven't read the book, but by reading the table of contents, it does look like it is essays on commonly known topics to most programmers.
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'm also curious about this, and interested in a review from someone who has been in the field longer to see how much the advice here rings true. 40 dollars isn't a huge ask for a book, but it's above an impulse buy.
I am not downvoting you, but (if GP is accurate) 2 years of professional experience is nothing, and to be an authority is laughable. To say he established himself as a developer marketer, ok, but damn, really? 2 Years? When I started to work 2 years was junior level developer, and now they are authorities??
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.
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)
Ok so why would any of that matter? He’s giving you advice on how to get a senior title fast, not on react or CS or engineering at all. Just the fast title acquisition.
Who’s better for that advice? Someone who did it in 2 years or someone who took 10?
It matters because he (in my point of view) isn't a senior and is lying about it? Because due to the dynamics of easy money and the lack of developers, you got 2 year bootcamp graduates getting 'senior' titles but being just beyond the junior marker.
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.
As a bystander but friend of Shawn's, I can say that over the last few years he has demonstrated an incredible ability to quickly learn and master concepts, then pass that information on to others.
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:
I think GP's point is that I would be similarly skeptical of taking parenting advice "from diapers to diplomas" from someone who hadn't yet had their first-born blow out a birthday candle, regardless of how well-edited or how much effort they put into publishing that advice.
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.
> What qualifies you to instruct people how to manage their dev career
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?
Agreed. If the author had 40 years experience I would pay attention but 2 years experience is nothing. Maybe it should be sold as "what to expect in the first 2 years of your career".
About the $40+ for the advice part - seriously, that is a few hours of developer salary. Compared to the few days it would take reading, it is essentially nothing.
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 am frankly a bit tired of this kind of bait-clicky lessons from people with a very thin track record. (This is way too frequent on Youtube these days)
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.
Hi HN! I have been writing since April, but this book has been years in the making. So glad to launch it today!
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!
Was 2017 the time you switched careers from finance and learned to code via freeCodeCamp? Or did you switch before 2017 but started learning new stuff (say a new language) on freeCodeCamp in 2017? If it is the former, that's great progress getting to Senior level in less than 3 years! Congrats
short form - i started doing FCC in nights and weekends from Nov 2016 - Mar 2017, then quit and went all in in Jun 2017 and went to an NYC bootcamp to top up my FCC knowledge and also get my first dev job.
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.
This looks like a great resource, swyx. I'm considering buying but would strongly prefer to read a physical book. Do you plan to publish a print version?
thanks! I have no immediate plans but am open to the idea - if only for the fact that itd be freaking cool to give out my own book - any idea what the best way to do a small print run of books would be?
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.
thank you! yes in fact v0.1.x of the book was published thru leanpub. but i found their build process buggy and nondeterministic - the same exact source material would sometimes succeed in building and sometimes fail, with no stacktrace or helpful error message. The leanpub founders are aware of this, but to save my sanity after a 5 hour session randomly debugging from a distance i had to leave
Thanks for the insights! I've used leanpub a bit and have seen some bugs, but also found the owner really helpful in fixing these so I kept with them for now.
I asked on twitter privately if swyx the writer can pass on a discount code as I am in between jobs, and due to the USD exchange rate it works out quite expensive in my home country and most kindle downloads have been about 1/4 of the price of this book. He gave a very curt reply, and when I went to check out the book again it had actually gone up from 40 usd to 59 usd, with 3 tiers of pricing where for 99 usd or 249 usd u get extra things like audiobooks and 'future courses'. I understand he came from a finance background that may have influenced his behaviour, but considering his target audience would be junior developers who don't earn that much especially outside USA, it feels quite exploitative especially during covid-19 times.
Read a version of this book pre-release and loved it!
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
thanks a TON forrest! your advocacy and lending your platform to help give a leg up to others in our industry has been super inspiring to me and I hope to do the same in future!!
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...
There's a lot more than two conditions there, and turns me off trying. Even though, I could probably use the networking.
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.
what is meant by “easily-grasped” in this case, and why is being this type of person good? I.e. why would it be good to have a skill that anyone can easily grasp?
(I’m sure it’s mentioned in the book, but I couldn’t help but ask anyway :])
Poor choice of words on my part. Should have said something like "easily-grasped value prop". You want a very short elevator pitch for what you do, that makes it clear what value you provide.
I think of Corey Quinn, whose pitch is "I fix your AWS bill." Short, easily-grasped, specific.
this exactly. but Corey can also pitch himself in anywhere from 30seconds to 30 minutes. Marketing Yourself is about adjusting your message to your audience/situation, and it can and should be practiced because you do not leave things like this up to chance. (the public draft: https://www.swyx.io/writing/marketing-yourself/)
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."
i'm sorry i made you feel that way. this is far from the only valid perspective on the industry and I'd be interested in reading what you prefer/enjoy instead.
hi! - there wasn't - this is a result of my noobyness doing this - but now there is! i've put up 4 chapters for you to evaluate - no email needed. https://www.learninpublic.org/#learn-more
This book looks interesting. I'd like some advice on whether it will be useful for me.
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.
you have more experience than i do, so your call on deciding whether you have a superset on this content. all i can offer is, if you do choose to check it out and decide it is not for you, I will honor your refund request.
Good luck! I am certainly always on the side of developers working on themselves.
Any free version I can audit? Not convinced this is worth the money since you have 2 years of experience, but I am willing to invest some time to prove myself wrong.
I'm curious enough about some of the content in this book that I'd consider reading it if the price was cheaper (maybe $10-15 or so).
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.
naming is hard... so the background on this is that the book was originally called "Cracking the Coding Career" for the alliteration and for the mirror with "Cracking the Coding Interview". I nearly even shipped with that name - until Gayle McDowell got in touch and said this would break her trademark. So I had to tweak it. I considered maybe a dozen other names but believe it or not they were worse :(
Gayle's usage, "coding interview," specifies which part of the interview loop her book focuses on. Of course there are many other attributes and skills assessed in an interview loop: design, architecture, debugging, technical communication, experience, domain knowledge, leadership, etc.
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.
Shameless plug: my work-in-progress book Programming Without Anxiety [0] might be interesting for you. It got a bit of scope creep which I'll have to cut back on, but I'm pretty enthusiastic about the content so far.
Looks very interesting, even tough I'm not new in the industry. So I'm interested in buying and if like it I'd like to upgrade the package. Is it possible just by paying the difference? I couldn't find this in the FAQ
hello! Podia does allow "upsells" and I tried to do everything right to configure it such that you just pay the difference if you do. however i havent run thru this userflow myself. if you do wanna upgrade later and have trouble just ping me, i'll sort you out manually
I highly doubt sales would increase by 10x, or even 2x.
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".
I did not point to him being a senior engineer at FAANG, I pointed to him mentioning that he's a senior engineer at FAANG, as evidence that the book is marketed towards people who also want to become senior engineers at FAANG.
As mentioned in my original comment, I fully realize that plenty of people couldn't care less about becoming senior engineers at FAANG, and am not making any claims about the intelligence or qualifications of the author or the quality of the book.
Tech Lead is walking meme who rarely offers good advice, most of which should be taken with a grain of salt. His life is currently a mess: He's divorced and has been recently been accused of doxxing YouTubers and other people who criticize his work.
I highly recommend this book and Swyx's other work. He's thorough while also distilling down to the most important bits.
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).
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.