Don’t meet your heroes. I paid 5k to take a course by one of my heroes. He’s a brilliant man, but at the end of it I realized that he’s making it up as he goes along like the rest of us.
This is a valuable realization. The first ten years or so of my career I believed that somewhere out there were people who Always Got It and who Did It Right and that I just hadn’t encountered them yet. It was liberating to see people I had admired from afar up close, and to realize that even though they were brilliant they were also fallible and also winging it pretty often.
(Admittedly I didn’t pay $5,000 to see that, I’d possibly be annoyed about that part as well!)
I have met my heroes a couple times, and I found new ones. It is funny to think about how you would imagine it goes. Sometimes they are what you think they are, other times nothing even remotely close. What they all are is infact human.
Do meet your heroes, just have the right expectation on both sides. Your actual heroes will be accidental.
There’s a lot of good stuff in here that we all think everyone knows and we say to each other in the pub but we don’t really say out loud to the people that need to hear it.
The main one that comes to mind is about mobility. They said something like “if I get fired I’ll have a new job in two weeks.” The tech folks that don’t know this is true need to learn it. More importantly: the people who manage tech people need to learn it.
Imma guess it depends on where you are. Silicon Valley, Seattle, NYC, London, you can basically put your desk stuff in a box, and throw it out a window and have it land in another tech company’s lobby.
I agree living in a tech hub makes finding a job way easier, but I jump to temper the hyperbole just a bit. I know that I personally felt a lot of self-hatred when I tried to change jobs and it took months of applications and references and interviews to actually get one, even living in a tech hub.
Technology stacks don’t really matter because there are like 15 basic patterns of software engineering in my field that apply. I work in data so it’s not going to be the same as webdev or embedded.
It depends on what you do. The author is a database specialist, so of course they’re going to claim that SQL is the ultimate language and that jobs are plentiful. I’m an SRE, so my career path requires me to pick specific backend-ready languages to learn. I have several great memories of failed interviews because I didn’t have precisely the right tools under the belt:
I worked on a Free Software library in Python along with other folks. They invited me to interview at their employer. Their employer offered me a position writing Lua for production backends. To this day, I still think that this was a bait-and-switch.
I interviewed at a local startup that was personally significant in my life. I had known that it wasn’t a good fit. Their champion had just quit and left behind a frontend written with the trendiest JS libraries, locking their main product into a rigid unmaintainable monolith. I didn’t know the exact combination of five libraries that they had used.
I interviewed at a multinational group for a position handling Kubernetes. I gathered that they had their own in-house monitoring instead of Prometheus, in-house authentication, etc. They also had a clothing line, and I’m still not sure whether I was turned down because I didn’t already know their in-house tools or because I wasn’t wearing their clothes.
They also had a clothing line, and I’m still not sure whether I was turned down because I didn’t already know their in-house tools or because I wasn’t wearing their clothes.
Seems like a blessing in disguise if it was the clothes.
I have this problem and I’m in a tech hub. Most of my coworkers and technical friends are in different countries I can’t legally work in, so I rarely get interviews through networking. Interviewing is also not smooth sailing afterwards.
There’s a lot of good stuff in here that we all think everyone knows and we say to each other in the pub but we don’t really say out loud to the people that need to hear it.
Interesting that you say that in the context of modern IT. It has been so with many things since ancient time.
Perhaps the traditional after-work Friday beer plays a more important role in one’s career than most people think. Wisdom is valuable and not available ons course you can sign up to.
The main one that comes to mind is about mobility. They said something like “if I get fired I’ll have a new job in two weeks.” The tech folks that don’t know this is true need to learn it. More importantly: the people who manage tech people need to learn it.
Retention is a big problem. It can take up to a year to ramp up even a senior person to be fully productive on a complicated legacy code base. Take care of your employees and make sure they are paid a fair wage and not under the pressure cooker of bad management who thinks yelling fixes problems.
I agree so much about the documentation. It’s hard. It’s not just about making sure that everything is there, unless you’re strictly writing a reference perhaps, but making sure that it is introduced in an order and pace that the intended target audience (which is not you by the way, so who is it?) can be assumed to learn it. And those people cannot read your mind, only what you wrote; if it’s ambiguous they will make the other interpretation.
Conversely, if there is a call for document review for some thing you will be an end user of, or which contains the thing you work on, or any other reason for why you might know of the document review in the first place – put time into it, it will most likely save everyone time in the long run.
This, this, this! There are a lot of books and articles online that talk about writing as following a series of rules (e.g., omit needless words, use the active voice, keep your sentences short, do not end a sentence with a preposition, etc.), but you’ve nailed exactly what writing is about: it’s about the target audience. It’s about writing in a way that they’ll gain value from reading. The rules about language can be useful, but they’re useless if the author failed to understand what his audience needed.
There’s a video online that I quite like. The first time I saw it, I was shook to my core, but I’ve come to realize the wisdom of the advice in it. https://www.youtube.com/watch?v=aFwVf5a3pZM
I was just discussing this the other day with my wife (also a software engineer): there’s two things that nobody teaches you:
How to write good documentation (and more importantly, how to write a simple project specification and keep the conversation going so that most of the high-level items are ironed out before you write the first line of code)
What, how and why to test your code
Two huge endeavors that improve the quality of the code immensely are never touched on in academia and are not emphasized as part of your job once you enter the industry. I was mind-blown by just bad documentation was when I worked at Google. Another thing I did realize early on is that one’s ability to get promoted was directly correlated with how well they documented their work. You could spend months working on a super important project, but if you were shit at documenting the importance of the project and the progress you were making, the promo committee had 0 visibility into your work.
Honestly, I think there’s a fair market opportunity for creating courses around this and selling them to companies.
I think it’s weird that these two are in the same category. You can’t write any non-trivial code (or even much trivial code) without reading documentation on the things that it wants to interoperate with (even if that’s only the core standard library for your language). It’s impossible to be even a junior developer without being exposed to good and bad documentation. I don’t understand how anyone can be exposed to so many exemplars and not learn. Even if you work entirely on your own, you’ve almost certainly come back to a project that you haven’t looked at for a year and either gone ‘I’m so glad I documented this well, it’s really obvious what I was doing’ or ‘I have no idea what I was thinking when I wrote this’.
Writing good documentation is really just a matter of putting yourself in the mind of the person approaching your codebase for the first time (or after a sufficiently long gap that they’ve forgotten). That person is very much likely to be you in a year’s time, so being able to write good documentation depends only on being able to empathise with yourself, which should be easy!
Testing is very different. Tests don’t show their value until a project reaches a certain level of complexity. It’s possible to work on a load of simple self-contained things and not really experience first-hand the benefit of tests. The value of a good test suite is really obvious if you’ve worked on a big project that has one but is far less obvious when you only work without one. I really hated the requirements that the LLVM project had on writing regression tests for every new feature and bug fix when I started working on it but I lost count of the number of times I was saved work by having a bug easily reproduced by a test.
I think the big problem with a lot of academic teaching in software engineering is that they don’t treat it as a social enterprise. Everyone works on their own project (or, occasionally, in small groups) and then the code is thrown away at the end of the year. I taught a compilers course to the Cambridge MPhil group and most of the students had never worked on a project that was >10KLoC before. I like to think that they learned a lot about compilers, but the most valuable transferable skill was probably having to read LLVM API documentation and write things that integrated with a library that was over a million lines of code from a standing start.
I’d love to have a course where every year people had to fix bugs from the previous cohort’s project and then add new features and hand it over to the next cohort and where the grades for each cohort depended on the experiences of the following one (or, ideally, of the next two or three).
I’ve worked at Sauce Labs for several years helping people debug tests and test frameworks, and have come across just so much bad documentation and testing practise… And been so impressed at the difference when those things are good, instead.
The thing that’s blown my mind as a Big Boy (eg professional dev with experience) is how little of this stuff people can get away with doing, even as a senior. My college degree was run by the engineering school, and I’ve worked in Engineering firms, and that shit does not fly in other industries; You document and test properly even if you don’t want too, or you’re fired.
Practice will make anything better. This is why writing a weblog is useful even if no one reads it (or even if you don’t publish it!)
Doing it twice is like code: the first time you usually don’t quite know what you’re doing yet as you don’t fully understand the problem, eventually you come up with something that works but isn’t necessarily the best. So you write it again, sometimes just parts of it, sometimes even from scratch. Because you now know all the things you didn’t know when you wrote the first line it will be better.
I did this today actually; I’ve been working on some tools to extract stuff from Baldur’s Gate (a game), and there’s some documentation out there but it’s all rather meh. While writing the implementation I also wrote quite a bit of documentation for it explaining how it all works. When I continued to work on it today I rewrote a bit of the code, but a lot of the documentation. The gist is still the same, but now that I understand it better the documentation is much better, too.
Often times coming back to it after a few days is very helpful. You’re not longer “immersed” in the material and whatever is unclear tends to stick out.
I don’t think any of this is hard as such, it just requires more time than many people are willing to invest.
Talks work like this as well; my talks don’t “emerge” from the notes and slides until I’ve written them once, tried to give them to the wall and decided I hate everything I’ve written and I’m a fraud and a sham.
Even after that, giving them to someone who is willing to give good feedback is incredibly valuable. I got the ‘best presentation’ award at ASPLOS a few years ago. I gave a practice talk to some folks in my department and got two hours of feedback from a 15-minute talk. The final version had almost no relationship to the version that I have as a practice talk, and I gave the practice talk because I thought the talk was basically ready.
If you learn to dance, the value of feedback becomes apparent really quickly. Folks who start doing tango often get excited and practice a lot with another beginner. After a few weeks, they’ve really entrenched some bad habits and then they need to spend several months unlearning them. Feedback early and often is a really hard habit to get into (nobody likes having their early attempts criticised) but it’s so very valuable.
“Do it at least twice.” is a great way to put it. Whenever I’m working on something nontrivial, I always get something that works somehow, someway with the explicit plan of rewriting all of the terrible hacks I resorted to because I didn’t understand what I was doing yet.
You might spend a long time (hours, days) on something like a proof of concept and meet failure. Internally, you’ll feel defeated. Turn this into something positive by reflecting and documenting what you tried and what you learned.
As long as you don’t become dogmatic! “I don’t have the skills/understanding to do X” can’t become “No-one has the skills or understanding to do X” or you turn into that guy who spends all their time looking like they’re sucking on a lemon and crapping all over everyone else’s work.
I’d work with this dude.
I’d drink with him too
This is a valuable realization. The first ten years or so of my career I believed that somewhere out there were people who Always Got It and who Did It Right and that I just hadn’t encountered them yet. It was liberating to see people I had admired from afar up close, and to realize that even though they were brilliant they were also fallible and also winging it pretty often.
(Admittedly I didn’t pay $5,000 to see that, I’d possibly be annoyed about that part as well!)
I have met my heroes a couple times, and I found new ones. It is funny to think about how you would imagine it goes. Sometimes they are what you think they are, other times nothing even remotely close. What they all are is infact human.
Do meet your heroes, just have the right expectation on both sides. Your actual heroes will be accidental.
There’s a lot of good stuff in here that we all think everyone knows and we say to each other in the pub but we don’t really say out loud to the people that need to hear it.
The main one that comes to mind is about mobility. They said something like “if I get fired I’ll have a new job in two weeks.” The tech folks that don’t know this is true need to learn it. More importantly: the people who manage tech people need to learn it.
This has never been true for me. Job hunting has always been a relentless slog.
Imma guess it depends on where you are. Silicon Valley, Seattle, NYC, London, you can basically put your desk stuff in a box, and throw it out a window and have it land in another tech company’s lobby.
Other places, not so much.
I agree living in a tech hub makes finding a job way easier, but I jump to temper the hyperbole just a bit. I know that I personally felt a lot of self-hatred when I tried to change jobs and it took months of applications and references and interviews to actually get one, even living in a tech hub.
It depends on what you do. The author is a database specialist, so of course they’re going to claim that SQL is the ultimate language and that jobs are plentiful. I’m an SRE, so my career path requires me to pick specific backend-ready languages to learn. I have several great memories of failed interviews because I didn’t have precisely the right tools under the belt:
Seems like a blessing in disguise if it was the clothes.
I have this problem and I’m in a tech hub. Most of my coworkers and technical friends are in different countries I can’t legally work in, so I rarely get interviews through networking. Interviewing is also not smooth sailing afterwards.
Same here, I also live in a city with many startups, but companies I actually want to work for, which do things I think are worthwhile, are very rare.
Interesting that you say that in the context of modern IT. It has been so with many things since ancient time.
https://en.wikipedia.org/wiki/In_vino_veritas
Perhaps the traditional after-work Friday beer plays a more important role in one’s career than most people think. Wisdom is valuable and not available ons course you can sign up to.
Which is ironic given wisdom is often what they’re being sold as providing.
Retention is a big problem. It can take up to a year to ramp up even a senior person to be fully productive on a complicated legacy code base. Take care of your employees and make sure they are paid a fair wage and not under the pressure cooker of bad management who thinks yelling fixes problems.
That’s probably why the OP says their salary went up 50% while their responsibilities reduced by 50%. Onboarding.
I quit my last job partially over this, at about the same paging rate :)
Quit my first job after I was called every night around 1AM during my one week on-call rotation.
Oh, well, he goes on.
I mean, I believe many of us can relate to finding beer and as a result keeping going
I agree so much about the documentation. It’s hard. It’s not just about making sure that everything is there, unless you’re strictly writing a reference perhaps, but making sure that it is introduced in an order and pace that the intended target audience (which is not you by the way, so who is it?) can be assumed to learn it. And those people cannot read your mind, only what you wrote; if it’s ambiguous they will make the other interpretation.
Conversely, if there is a call for document review for some thing you will be an end user of, or which contains the thing you work on, or any other reason for why you might know of the document review in the first place – put time into it, it will most likely save everyone time in the long run.
This, this, this! There are a lot of books and articles online that talk about writing as following a series of rules (e.g., omit needless words, use the active voice, keep your sentences short, do not end a sentence with a preposition, etc.), but you’ve nailed exactly what writing is about: it’s about the target audience. It’s about writing in a way that they’ll gain value from reading. The rules about language can be useful, but they’re useless if the author failed to understand what his audience needed.
There’s a video online that I quite like. The first time I saw it, I was shook to my core, but I’ve come to realize the wisdom of the advice in it. https://www.youtube.com/watch?v=aFwVf5a3pZM
I was just discussing this the other day with my wife (also a software engineer): there’s two things that nobody teaches you:
Two huge endeavors that improve the quality of the code immensely are never touched on in academia and are not emphasized as part of your job once you enter the industry. I was mind-blown by just bad documentation was when I worked at Google. Another thing I did realize early on is that one’s ability to get promoted was directly correlated with how well they documented their work. You could spend months working on a super important project, but if you were shit at documenting the importance of the project and the progress you were making, the promo committee had 0 visibility into your work.
Honestly, I think there’s a fair market opportunity for creating courses around this and selling them to companies.
I think it’s weird that these two are in the same category. You can’t write any non-trivial code (or even much trivial code) without reading documentation on the things that it wants to interoperate with (even if that’s only the core standard library for your language). It’s impossible to be even a junior developer without being exposed to good and bad documentation. I don’t understand how anyone can be exposed to so many exemplars and not learn. Even if you work entirely on your own, you’ve almost certainly come back to a project that you haven’t looked at for a year and either gone ‘I’m so glad I documented this well, it’s really obvious what I was doing’ or ‘I have no idea what I was thinking when I wrote this’.
Writing good documentation is really just a matter of putting yourself in the mind of the person approaching your codebase for the first time (or after a sufficiently long gap that they’ve forgotten). That person is very much likely to be you in a year’s time, so being able to write good documentation depends only on being able to empathise with yourself, which should be easy!
Testing is very different. Tests don’t show their value until a project reaches a certain level of complexity. It’s possible to work on a load of simple self-contained things and not really experience first-hand the benefit of tests. The value of a good test suite is really obvious if you’ve worked on a big project that has one but is far less obvious when you only work without one. I really hated the requirements that the LLVM project had on writing regression tests for every new feature and bug fix when I started working on it but I lost count of the number of times I was saved work by having a bug easily reproduced by a test.
I think the big problem with a lot of academic teaching in software engineering is that they don’t treat it as a social enterprise. Everyone works on their own project (or, occasionally, in small groups) and then the code is thrown away at the end of the year. I taught a compilers course to the Cambridge MPhil group and most of the students had never worked on a project that was >10KLoC before. I like to think that they learned a lot about compilers, but the most valuable transferable skill was probably having to read LLVM API documentation and write things that integrated with a library that was over a million lines of code from a standing start.
I’d love to have a course where every year people had to fix bugs from the previous cohort’s project and then add new features and hand it over to the next cohort and where the grades for each cohort depended on the experiences of the following one (or, ideally, of the next two or three).
Yes.
Yes yes Yes yes YES YES YES.
I’ve worked at Sauce Labs for several years helping people debug tests and test frameworks, and have come across just so much bad documentation and testing practise… And been so impressed at the difference when those things are good, instead.
The thing that’s blown my mind as a Big Boy (eg professional dev with experience) is how little of this stuff people can get away with doing, even as a senior. My college degree was run by the engineering school, and I’ve worked in Engineering firms, and that shit does not fly in other industries; You document and test properly even if you don’t want too, or you’re fired.
In my experience there are two tricks:
Practice will make anything better. This is why writing a weblog is useful even if no one reads it (or even if you don’t publish it!)
Doing it twice is like code: the first time you usually don’t quite know what you’re doing yet as you don’t fully understand the problem, eventually you come up with something that works but isn’t necessarily the best. So you write it again, sometimes just parts of it, sometimes even from scratch. Because you now know all the things you didn’t know when you wrote the first line it will be better.
I did this today actually; I’ve been working on some tools to extract stuff from Baldur’s Gate (a game), and there’s some documentation out there but it’s all rather meh. While writing the implementation I also wrote quite a bit of documentation for it explaining how it all works. When I continued to work on it today I rewrote a bit of the code, but a lot of the documentation. The gist is still the same, but now that I understand it better the documentation is much better, too.
Often times coming back to it after a few days is very helpful. You’re not longer “immersed” in the material and whatever is unclear tends to stick out.
I don’t think any of this is hard as such, it just requires more time than many people are willing to invest.
Talks work like this as well; my talks don’t “emerge” from the notes and slides until I’ve written them once, tried to give them to the wall and decided I hate everything I’ve written and I’m a fraud and a sham.
Even after that, giving them to someone who is willing to give good feedback is incredibly valuable. I got the ‘best presentation’ award at ASPLOS a few years ago. I gave a practice talk to some folks in my department and got two hours of feedback from a 15-minute talk. The final version had almost no relationship to the version that I have as a practice talk, and I gave the practice talk because I thought the talk was basically ready.
If you learn to dance, the value of feedback becomes apparent really quickly. Folks who start doing tango often get excited and practice a lot with another beginner. After a few weeks, they’ve really entrenched some bad habits and then they need to spend several months unlearning them. Feedback early and often is a really hard habit to get into (nobody likes having their early attempts criticised) but it’s so very valuable.
Yup, 100%. One thing I love about digital talks during The Virus Times, is the ability to poll the audience at the end to ask for feedback.
Additionally, how is Tango going?
I injured my back and had to stop for a little bit and then the pandemic happened. Hoping to get back to it this autumn!
“Do it at least twice.” is a great way to put it. Whenever I’m working on something nontrivial, I always get something that works somehow, someway with the explicit plan of rewriting all of the terrible hacks I resorted to because I didn’t understand what I was doing yet.
Yes.
and yes.
Something not mentioned…
You might spend a long time (hours, days) on something like a proof of concept and meet failure. Internally, you’ll feel defeated. Turn this into something positive by reflecting and documenting what you tried and what you learned.
As long as you don’t become dogmatic! “I don’t have the skills/understanding to do X” can’t become “No-one has the skills or understanding to do X” or you turn into that guy who spends all their time looking like they’re sucking on a lemon and crapping all over everyone else’s work.