131–140 of 371 posts
3. Simplicity Fighting complexity is a never-ending cause. Solutions should be as simple as possible. Assume the next person to maintain your code won’t be as smart as you. When you can use fewer technologies, do so. This is the one I appreciate more and more as I age. Because frequently, I'm the next person looking at my own code. And there's no better gift to your future self than well-written, easy-to-understand c…
At a previous job, I was the only person to document architecture structure and design choices in a document in each repo I worked on. They turned out to be very helpful for the new employees we took on over my time there. While that's a great plus, the real reason I wrote those was for myself because there is no way in hell I'll remember how to deploy this app to a new EB instance.
In my last job, I wrote documentation so I could quickly get back into the context of the different problems I was working on. Context switching was a real challenge in that environment and I referred to my own documentation frequently. And sometimes, writing documentation helped me better understand the problem I was working similar to the idea that teaching a topic is a great way to learn.
Earlier quoted context omitted.
> As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs. So I have to ask: do you or have you worked at a FAANG with these systems? I may be wrong but I suspect you haven't, particularly if you're equating them with more traditional hierarchies. The whole point of a system like this (and I have direct experience at Google and Facebook) is so you can go pretty far as purely a…
> new hires start as a T3 This makes me curious about what T1 and T2 would mean.
3. Simplicity Fighting complexity is a never-ending cause. Solutions should be as simple as possible. Assume the next person to maintain your code won’t be as smart as you. When you can use fewer technologies, do so. This is the one I appreciate more and more as I age. Because frequently, I'm the next person looking at my own code. And there's no better gift to your future self than well-written, easy-to-understand c…
I came here to say the exact same thing, but I want to extend it a bit more. I've seen some developers, including myself, looking at some code and complaining "who the hell wrote this mess!", only to find out in repository history it was themselves. lol.
Earlier quoted context omitted.
Expecting a talented software engineer to "upgrade" to become a manager of a development team makes exactly the same amount of sense as expecting a talented accountant to gain a bit more skill and suddenly become a lawyer.
There are other paths at Google than upgrading to mgmt, but all of them involve "cross-team collaboration" and other quasi-political (with a small-p) aspects. Actually just writing code at Google is, from my experience, a small part of the job and not rewarded. The faster you get out of writing code and get into designing and delegating it, the better you're off. Sucks if you don't like it. Coming up with a way to re…
Part of that is that the big companies typically hire suits to do management - which were basically the jocks in high school that always got the girl... that type - they run everything in the world now. Loud mouth tech bro asshole types.
Earlier quoted context omitted.
I think they are doing themselves a disservice by ignoring something that elevates overall understanding, ease of onboarding/troubleshooting and generally, the polish, of the project. I love documentation and usually manage to set aside time to add details in the README/wiki etc. It is a great way to share details with others and myself, six months down the line, because I don't have a super sharp memory.
This is true but the “curse of knowledge” from the article explains why this can happen. It is easy for outsiders like you and me to see the value of such things but as an insider you can become blinded by your knowledge.
Earlier quoted context omitted.
First real job I had there was this guy who had one specialization. He was in charge of some software that drove tape drives. Every outside new manager would come in and in some form or another look down on this guy in some form due to his age and generally not doing "a lot" of tasks and new products. It took the local VP to come down and regularly high five him after his product git rave reviews from customers (regu…
That guy could perfectly be some tech lead, establishing his rock solid approaches on team of junior 4-10 engineers and delivering rock solid new products.
Earlier quoted context omitted.
> I wore a suit to my very first interview for a dev position and very nearly didn't get the job because they were worried I wouldn't fit in Yeah - I hate this. I had people at my last position give candidates negative points because they wore a suit and I went $%&#ing ape. In positions that I've held in the past it's been the appropriate action to wear a suit due to heavily corporate environments, and I see it as 11…
> The action of wearing a suit (or tie for that matter) to an interview should never be seen as a "cultural fit" problem I would agree and would go as far to say that dress in general should never be a hiring criteria for a non-customer facing position. Unless there are hygiene issues or they are wearing something actively offensive.
In a lot of my engineering roles I have had to be internal/external facing and do things like budget presentations, work with partners, etc. Before that, I was a general web/app dev and we would get pulled along to client meetings all the time to collect spec, ensure that it was a good sales fit, etc. I'm not saying I had to be fully decked-out but being able to throw on a button down and tuck it in means that you "fit-in" to these situations.
For me, if someone is showing up in a t-shirt and jeans it's a red flag that you can't be bothered to dress semi-professionally which has been an occasional (but hard) requirement of me since day-1 of my career. 100% this all is anecdotal, and specific to my own needs/experiences.
This is very wise: "When I was at GM, you were a failure if your next move was not up—managing more people or taking on bigger, more complex projects. For many, this made for a miserable career path" As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs. The "level" system encourages/pushes people to "upgrade" in this manner, and I think contributes to a number of problems.…
This is very wise: "When I was at GM, you were a failure if your next move was not up—managing more people or taking on bigger, more complex projects. For many, this made for a miserable career path" As I've said before, I think this is a corrosive aspect of the perf/promo process at many FAANGs. The "level" system encourages/pushes people to "upgrade" in this manner, and I think contributes to a number of problems.…
First real job I had there was this guy who had one specialization. He was in charge of some software that drove tape drives. Every outside new manager would come in and in some form or another look down on this guy in some form due to his age and generally not doing "a lot" of tasks and new products. It took the local VP to come down and regularly high five him after his product git rave reviews from customers (regu…
This isn't helped by the current trend of trying to hire mostly fullstack developers, also known as hiring one person to do the job of three people. It does almost nothing but incentivize packing resumes to hopefully make the cut and burn people out from switching modes.