People should respect you. It's your right to push back against disrespectful interactions. If it's waved away with "oh, [person] is just like that," know that a) that is bullshit and b) both the person being disrespectful AND the one dismissing it are wrong.
You can become a great developer EVEN if you spend your nights & weekends doing other things. Be focused, make those work hours count, and then leave your office and spend your free time out in the wider world.
Resist tribalism in all forms.
a) Your role as a software engineer isn't more or less important to the company than other roles.
b) Your place on the stack isn't more or less prestigious than other places.
c) The technology you use has its ideal use cases - and so do all the alternatives.
Anyone who justifies something by saying it's "an industry best practice" actually has NO IDEA why they're doing it. Push (gently, respectfully) to see if they can articulate the actual positive outcome they expect.
a) same goes for "idiomatic," "more elegant," and "cleaner"
Do not read Robert Martin's books, unless you're working at a large, old company - and in that case, view them as anthropological studies that will help you survive in an alien environment.
More seriously - they're written for a previous generation, and while they might help you understand the current crop of 'senior' developers better, their techniques and attitudes are out of date and won't be useful to you moving forward. You're in a new world! You have the chance to make a real impact with your communication and technical skills. Go out & do it your way.
I don't think they're entirely out of date for all developers, but I agree with Sarah's assessment for juniors. I specifically instruct juniors not to bother with that material early on in their career, but highly recommend it to folks who are a little further along—as great reference material, with some parts worth ignoring.
It's not that the advice and techniques are all out of date, but for juniors it could be hard to separate the dated from non-dated. It makes sense that an older book which covers a lot of ground would not stand up entirely over time.
I'm not speaking for Sarah's reasoning, but this is my answer for your question!
It's okay for everyone to write bad code sometimes. Not everything has to be perfectly structured and totally optimised. 'Tactical' can be good sometimes, and technical debt isn't always evil - as long as you aren't blind to it and have a plan to get rid of it or pay down the debt. Pragmatism is a key element of remaining commercial.
The fist 4 points apply to any employee in just about any job. Pretty much common sense. The 5th point is an unfortunate opinion. If the concepts in the Clean Code series were taught in college, we would an entirely different software landscape and the entire industry would be much more productive and less of a cause for stress. Thus allowing you more time to do what you love.
I could not agree more with point 5. Those books are a relic and most of the stuff in there has nothing to do with how software is actually built in the world (thankfully).
Which 'stuff' in those books do you disagree with? Is it the well structured code with sensible class, function and variable names and decent sized functioned, or the good OO practice and patterns or the properly tested code?
I’ve followed you for some time on twitter and most of what u say ressonate with me.
But this last point is plain wrong.
It disapoints me.
It makes me sad that u give such bad advice to new developers just because you have a grudge on UncleBob.
You should do some introspection and try to improve yourself as a person.
Seems most others answer the wrong question, either "how can a junior developer get to where I am?" (which was where my thinking went at first and why I felt uncomfortable giving an answer) or "what would I like my co-workers to be like?"
I would only like to add regarding point 1 that you also have a right to expect an environment where you are comfortable to speak and if that isn't the case it's never your fault. Any place where they think this happens automatically just because "we're all good people" is probably wrong in this, it needs to be actively encouraged.
So I guess the best advice I can give to juniors is that if there is something you want to change then "change your workplace or change your workplace." (don't remember who I'm quoting/paraphrasing)
You can become a great developer EVEN if you spend your nights & weekends doing other things. Be focused, make those work hours count, and then leave your office and spend your free time out in the wider world.
Totally agree with this. I really had my hair on fire for the first few months I got a job, all because I believed I needed to be programming all day AND night. I only realized that could not be the answer when I found myself burnt out from programming in an actual job setting working with actual people. Spending 6 - 8 hours doing something was already plenty of practice. Taking care of myself was still required, and when I did so I became a better engineer (and better everything).
Yeah, the difference between Clean Code and this advice column is time and evidence. There's evidence that the concepts taught in clean code work well and there's been plenty of time and happy developers to see it. Other than a pat on the back and a blackballing of Bob, I doubt there will be little useful substance from this piece in more than a few months of a young developer's life...stuff that they already didn't know or outgrow. It's common sense. What isn't common sense how to organize and test code at every level. It's one of the most empathetic things you can learn for your team and the one thing no one knows how to do out of school. I've seen devs drowning in complexity and domain with no way to organize or think about it. Then the framework abuse happens cause they don't know the concepts behind what makes the framework work. This is just advocating the kind of blind solipsism it claims to reject. Talk about tribalism.
Yes, "you're in a new world! Go out & do it your way!" Ignore best practices! Feel empowered and special, ignorantly making the same mistakes that created mountains of awful legacy code left by the last generation of coders. Later, you can enjoy your "participant" trophy while professionals try to clean up the inscrutable, unmanageable, buggy hacks you've left behind!
You deserve to be treated respectfully until you don’t deserve it.
You can become a good programmer even if you don’t spend your free time advancing your skills. It’s ok to not be great, but be mindful that there are those with passion who put in extraordinary effort to learn their craft. Don’t expect to get the same results without the same effort.
Not all roles are equal in all companies. That’s the reality of life.
Industry best practices do exist, and yes it’s good to be able to articulate why it’s a best practice. However doing something because that’s how others do it does not make it wrong. Learn why it’s a best practice.
Read Uncle Bob’s Clean Code and Clean Architecture books. Watch his videos. Learn something about writing software which won’t be out of date in a couple years. A lot of the technology skills we learn, although important, depreciate very quickly and so are very costly to maintain. What Uncle Bob teaches keeps its value.
People should respect you. It's your right to push back against disrespectful interactions. If it's waved away with "oh, [person] is just like that," know that a) that is bullshit and b) both the person being disrespectful AND the one dismissing it are wrong.
You can become a great developer EVEN if you spend your nights & weekends doing other things. Be focused, make those work hours count, and then leave your office and spend your free time out in the wider world.
Resist tribalism in all forms.
a) Your role as a software engineer isn't more or less important to the company than other roles.
b) Your place on the stack isn't more or less prestigious than other places.
c) The technology you use has its ideal use cases - and so do all the alternatives.
Anyone who justifies something by saying it's "an industry best practice" actually has NO IDEA why they're doing it. Push (gently, respectfully) to see if they can articulate the actual positive outcome they expect.
a) same goes for "idiomatic," "more elegant," and "cleaner"
Do not read Robert Martin's books, unless you're working at a large, old company - and in that case, view them as anthropological studies that will help you survive in an alien environment.
More seriously - they're written for a previous generation, and while they might help you understand the current crop of 'senior' developers better, their techniques and attitudes are out of date and won't be useful to you moving forward. You're in a new world! You have the chance to make a real impact with your communication and technical skills. Go out & do it your way.
Why do you think that Robert Martin’ books are out of date ?
I don't think they're entirely out of date for all developers, but I agree with Sarah's assessment for juniors. I specifically instruct juniors not to bother with that material early on in their career, but highly recommend it to folks who are a little further along—as great reference material, with some parts worth ignoring.
It's not that the advice and techniques are all out of date, but for juniors it could be hard to separate the dated from non-dated. It makes sense that an older book which covers a lot of ground would not stand up entirely over time.
I'm not speaking for Sarah's reasoning, but this is my answer for your question!
So it's okay for junior devs to write bad code early in their careers?! What a bizarre attitude
It's okay for everyone to write bad code sometimes. Not everything has to be perfectly structured and totally optimised. 'Tactical' can be good sometimes, and technical debt isn't always evil - as long as you aren't blind to it and have a plan to get rid of it or pay down the debt. Pragmatism is a key element of remaining commercial.
The fist 4 points apply to any employee in just about any job. Pretty much common sense. The 5th point is an unfortunate opinion. If the concepts in the Clean Code series were taught in college, we would an entirely different software landscape and the entire industry would be much more productive and less of a cause for stress. Thus allowing you more time to do what you love.
I could not agree more with point 5. Those books are a relic and most of the stuff in there has nothing to do with how software is actually built in the world (thankfully).
Would you care to post a sample of your code? I assume it is miserable. Because your attitude is very odd
I have programmed in a bunch of professional contexts and never had a complaint. All without that miserable character.
Which 'stuff' in those books do you disagree with? Is it the well structured code with sensible class, function and variable names and decent sized functioned, or the good OO practice and patterns or the properly tested code?
I’ve followed you for some time on twitter and most of what u say ressonate with me.
But this last point is plain wrong.
It disapoints me.
It makes me sad that u give such bad advice to new developers just because you have a grudge on UncleBob.
You should do some introspection and try to improve yourself as a person.
Thank you for a great answer.
Seems most others answer the wrong question, either "how can a junior developer get to where I am?" (which was where my thinking went at first and why I felt uncomfortable giving an answer) or "what would I like my co-workers to be like?"
I would only like to add regarding point 1 that you also have a right to expect an environment where you are comfortable to speak and if that isn't the case it's never your fault. Any place where they think this happens automatically just because "we're all good people" is probably wrong in this, it needs to be actively encouraged.
So I guess the best advice I can give to juniors is that if there is something you want to change then "change your workplace or change your workplace." (don't remember who I'm quoting/paraphrasing)
Totally agree with this. I really had my hair on fire for the first few months I got a job, all because I believed I needed to be programming all day AND night. I only realized that could not be the answer when I found myself burnt out from programming in an actual job setting working with actual people. Spending 6 - 8 hours doing something was already plenty of practice. Taking care of myself was still required, and when I did so I became a better engineer (and better everything).
All amazing advice Sarah!
I've heard Robert Martin books recommended over and over again, so really appreciate this thought!
Uncle Bob is politically conservative. Sarah finds him offensive, so she's added an attack against him to the end of her otherwise excellent advice.
Sarah should heed her own advice about tribalism.
Yeah, the difference between Clean Code and this advice column is time and evidence. There's evidence that the concepts taught in clean code work well and there's been plenty of time and happy developers to see it. Other than a pat on the back and a blackballing of Bob, I doubt there will be little useful substance from this piece in more than a few months of a young developer's life...stuff that they already didn't know or outgrow. It's common sense. What isn't common sense how to organize and test code at every level. It's one of the most empathetic things you can learn for your team and the one thing no one knows how to do out of school. I've seen devs drowning in complexity and domain with no way to organize or think about it. Then the framework abuse happens cause they don't know the concepts behind what makes the framework work. This is just advocating the kind of blind solipsism it claims to reject. Talk about tribalism.
Yes, "you're in a new world! Go out & do it your way!" Ignore best practices! Feel empowered and special, ignorantly making the same mistakes that created mountains of awful legacy code left by the last generation of coders. Later, you can enjoy your "participant" trophy while professionals try to clean up the inscrutable, unmanageable, buggy hacks you've left behind!
Could not agree more
It's too bad I can only click the ❤ once