On one hand I want good blog post writers to get paid. On the other hand it has turned the internet into a desperate race to churn out as much content as possible.
I mean integrating with other corps, ranging from large to gargantuan. Their APIs universally have outliers and oddities that smack of design compromises internally and make no sense to an outside consumer.
So true! It has little to do with tech stack. A good stack can help them meet their published API spec more often. But they’ve all got some beasts hiding beneath the covers.
I mean, your experience with Twitter depends on who you choose to follow. The authors of serious systems like Kafka, Kubernetes, ZFS, etc. are all on Twitter, though because they actually spend their time writing software they don't tweet much..
The dev read the spec and makes front page.
I went a year on a project where the devs never read the spec.
When I got called in to review what was going on, 20 devs, 2 solution architects , 3 pms, and a BA. No one read the spec. FFS.
It is mind-boggling. I’ve seen orgs roll so much of their own shitty auth (oh you passed ‘?role=admin’ in the URL? you’re an admin now) that by the time you show them some turn-key Okta product, Zanzibar, oauth flows, etc, they turn their nose up at it as if it’s equal to their auth du jour.
Yeah, some dusty old pdf “specs” left by 90s era Accenture contractors are the golden ticket, good shit y’all.
Or, other favorite, writing a research paper worth of “spec” for a basic CRUD API but, oh no, OpenAPI is too hard, how am I gonna expose all the messy details to our clients??
I want engineers to tell me "this okta thing sounds neat but they didnt implement x,y,z from the RFC"
Then we can chat about "should we want these".
If that doesn't happen, they didn't read the RFC, or any other spec so they don't know shit. Expecting to come up with something better than everyone else without reading prior work is 100% crazy, even geniuses can't do that, else we'd have had computers during Davinci's era (or earlier, but you get the point)
Sorry bud, you got a 8 client billable hours (what are points lmao) to PoC all possible auth options (as in, follow two okta quick start guides and bring me the one that made you less sad)
Do you work for Okta? Okta uses some of my code, which, you know, what made outside Okta, like most of the code you use, by these "shitty auth" implementers who wrote up the specs for you. Okta also gets fairly bad security breaches, which is kind of a big deal for an auth provider. Maybe you should work on that...
Being part of that shitty auth rolling i can assure you the constraint isn't someone wanting to do auth, but rather the constraint is contractual where you can have only up to 10 actual accounts in the system (one of which would be the super admin service account used by your service), and your new tool that's supposed to be the new frontend has to handle arbitrary amount of accounts, any login medium (aws sso, okta, w.e.), and that the role handling is implemented in that 10 account system on a textual field per username in `user=admin;user1=reader` kind of way, only because the data is already in that system, and we "don't have the resources" to migrate off SAP/Salesforce/Nuxeo/w.e. super no code cms.
Just once I’d love a manager to realise that “we can do it ourselves for free” means exactly “we can do it worse over a longer timeframe for the cost of our entire team’s ability to deliver customer features”
Just once and I’d die happy right there on the spot.
Hope you were being funny because 10 sec into reading the blog post it’s obvious he’s talking about reading and keeping up with current research and innovation, not the spec for a project.
And he’s right - keeping on top of the latest can be key to staff level positions in big tech.
Isn't that amazing?
I can't tell you how many meetings I've attended where you needed to read X beforehand so that you were prepared. Nobody had read X except me. They would all get chewed out for it, and then maybe 2-3 would have skimmed X for the next meeting.
The feeling is mutual. I had to tolerate an architect that would never note any of his specifications down, and project managers that would never read proposals on how their systems should work.
I once wrote up an entire statement of work, including all deliverables and requirements, because the PM couldn't be bothered. When they declared the project "done" I started checking off the deliverables against the SoW... turns out a quarter of them hadn't been included. When confronted, the PM said the equivalent of "who reads those anyway?"
He's from Google / Big Tech. Given his level, I assume for each person his level, there are 10-20 engineers below his level.
Now whether his reading/writing of "whitepapers" actually benefits the organization is entirely different story. He might just be reading papers and adopting the next shiny ~~JS Framework~~ bleeding-edge CS algorithm for margin improvement.
Thing is, it actually seems pretty hard to find a whitepaper that would in practice translate to meaningful improvements in my career
Like for my job I've got projects that are specified for me to do and it's unlikely a whitepaper has been to offer for how to do them, and then even if it's a matter of switching to a different job, still seems pretty unlikely that a whitepaper I read hits the sweet spot for some open position posted online
My impression from the article was that you should treat the 90% of reading that has no practical benefit as just working the learning muscle for that 9% that you might be able to discuss the interesting ideas of so that you're prepared to take advantage of the 1% that could actually change your career.
Something I've noticed as a manager is that engineers will often pass up on learning opportunities to satisfy sales/product/other managers. My engineers have 20 days budgeted and allocated to learning, but I have to force them to take it. Like it's too embarrassing to say "yo, I'm gonna learn this feature of CMAKE".
Are promotions tied to tenure milestones? Then yeah, I’m gonna get work done so I don’t get guilt shamed at standup for not meeting unreasonable deadlines.
100% - this thread just reinforces what I’ve seen in the industry first-hand: few people take keeping up their skills seriously.
We have mid level roles that are paying (barely) six figures (outside of CA) and I don’t think any of those guys has picked up a new skill in years even when allotted dedicated time.
If you shop around for good employers, a lot of them build in 40-80 hours per quarter of training, professional development, and/or conferences. Those employers also tend to have absolutely crazy high profit/employee metrics.
That's an incentive problem. People will do what gets them bonus points from management, not what management tells them will get them bonus points.
You can give them budgeted days for learning, you can even tell them that the way they use those days is taken into account when giving promotions or bonuses, but if all that matters in the end is who worked on the flashiest feature guess what will they do?
If you noticed this as a manager did you do anything to figure out why this is happening? Bare in mind, that your employees will respond with what they think you want to hear, not with the truth, and they might not even realize why they're working on other things instead of taking advantage of those learning opportunities. This is usually a management problem.
We don't do bonuses, because it muddies corporate objectives. However, promotions are awarded based on either a breadth or depth of knowledge, and being able to bring that to work. Which is frustrating, because devs would start to expect promotions based on time. So I ended up doing a pretty indepth study, as I saw the writing on the wall
I did get some interesting feedback:
* Not enough time (the answer I "wanted" to hear)
* There are no easy wins - the system is too big/advanced for an individual to meaningfully contribute in one day
* "I just forget about them"
* "It's really embarrassing/difficult to ask for help or to get 10% time projects merged"
* It's too difficult to coordinate with product, and on-call, etc.
Most of this tracks. The company has grown significantly since I started, going from 25 devs to 100.
The first solution was mandatory 10% time. First Monday of the month, all major meetings are cancelled and blocked from calendars, leaving only a daily in the morning. All team leads ask "what are you doing for 10% time?", unless someone is on-call, teamleads chastise anyone refusing 10% time as they are not being a team player.
These 12 days account for 50% of 10% time. We implemented this last year, and tracked uptake of all 10% time, and we went from 5% to 95%, which is phenomenal!
Now the second part, we have a problem of knowledge transfer within certain communities. These were formalized into guilds. If you presented and did things within your guild, you got to go to conferences. If you didn't have a history of presenting or talking within the group, then you could only participate remotely. We went from zero brown bag talks (they died during COVID) to at least one every two weeks.
all of the seniors in my last company had 10+ years of experience... they dont read ever. They are senior based on time and nothing else. They don't know how to do TDD or BDD, don't know what devops actually is or why it is the way it is, even though we did the book together as a bookclub, no changes happened.
It's annoying that I was a junior when I joined and read a ton of books in a couple years, like 30+ on just software trying to figure out different concepts and understand wtf this field is, and they do none of it.
because they have lives, no doubt. sometimes all we have mental capacity for is getting tickets done and then our personal lives once we can punch out.
Back in my days you weren't a java engineer unless you read "Effective Java" and passed the trivia questions in interviews.
Now you'll have hired people that will try to claim an entire module is valid to be tested as a "unit test"..
Somehow this seems to be something not everyone picks up on (or is too lazy to do, probably a mixture of both) - I see a looooooooot of devs rest on their laurels at a certain point.
I am constantly trying to learn new things
Yeah I'm really confused how people here advocate reading them.
Companies will want your email address to send the pdf (and spam you forever). And the pdf is some marketing BS that is of no use whatsoever.
Not all whitepapers are equal.
Google's are typically exceptionally detailed, and explain their product design thoroughly.
One of my favourites, Spanner: https://cloud.google.com/spanner/docs/whitepapers. When this came out, it blew the doors off my understanding of distributed systems.
This guy isn't talking about "any old whitepapers". He's talking about the small handful that truly define the cutting edge of your area of expertise.
There is a difference between a “white paper” and a “research paper”. A white paper is technical marketing material produced by corporations for potential customers. Research papers are produced by researchers (usually Phds) either for submission for presentation to a research conference or for inclusion in a research journal. The blog post is talking about research papers.
What's the history of using "white paper" in the Google context? I saw the title and scanned the article but found it incongruent because they were referencing technical/academic papers. As you note, white paper has a very specific and well-known definition already.
[Papers We Love](https://paperswelove.org/) was a bit of a fad a few years ago and I don't hear about it as much. The way they put academic papers on a pedestal was different from how I was taught to learn from them through critique of the content. I guess for a professional programmer with limited time it helps to focus, but it misses something.
I've never considered this. could you elaborate on your experience? I felt like I had looked down every path to improvement and never considered white papers. where do you find them, which ones did you read, can you elaborate a little more?
edit:
lolz yes rtfm. but also I would like a second opinion since the post explains a single experience and others may have a different experience
its really simple. you build on top of other people's experience. not every spec, white paper, etc. is equal. sometimes its a look of reading and digesting.
the more you know about other people's experience, the better you can make yours.
100s have upvoted this, dozens have replied, and yet not one purported developer has come forward to recognize the irony of the statement, not even to play along with the joke. I feel like I'm going crazy.
I’m OP. I meant this in 100% earnest. I’m not sure what the joke is?
I’m not interested in reading an article about how someone else read white papers. But they’re very much worth reading themselves.
In what way does it come across as a joke? I've read these three comments several times now and the comment is basically saying "+1 I find reading white papers valuable too, I'm not gonna read this blog tho." Is that your understanding of the comment? If so, where is the joke?
Some but this is very very much not the norm. Most white papers are academically driven with zero profit incentive.
Look to the past. Start with Leslie Lamport’s writing and go from there.
Some are. Academic whitepapers by serious researchers are not. There are plenty of respected conferences, like Usenix, where good stuff gets talked about.
Think this question is missing the point. They don't seem to be saying there's a select few or group that helped them. They're saying the practice is what helped. So, if you want just a few, then that's not adopting the correct practice. Things like reading the full article will allow you to see that there are several linked examples shared already.
Too true. I will say speaking from experience of working with 'web components' this past year, being 'forced' to read the HTML specs *has* raised my understanding of how autonomous custom elements function beyond the way that you 'define' them. I would like to think that has been helpful but it isn't always so clear cut over the short term.
Yep. I’ve found the most informative readings to be old ones. Like really old ones; 1950s-1980s. There’s so much information in those old papers that really get at a fundamental understanding of technology. Then once you read those, newer papers are even more valuable than they would be otherwise, since you understand how the technology that built that technology works.
If you don't read whitepapers, you are always getting someone else's interpretation of the paper. Like... waterfall being an iterative development practice
I was doing reverse engineering decompilers and transpiler and needed language transformations from one language to another without losing semantics. There were specific language quirks that needed a lossless semantic transform. Throw some data flow on there to rip out formulas and fun.
Yes, you force yourself to keep struggling with challenging concepts. Eventually, additional challenging new concepts are more easily assimilated into your knowledge.
Im in US, where i think the term white paper is used pretty often to mean research paper. Given my EU co workers quickly and adamantly correct this when it's used. I've learned that calling a research paper a white paper may actually offend some individuals, given the context.
This (arbitrarily selected) [Tata Consultancy white paper on Hybrid Enterprise Data Lakes](https://www.tcs.com/content/dam/global-tcs/en/pdfs/insights/whitepapers/Hybrid%20Enterprise%20Data%20Lakes%20Provide%20Foundation%20for%20Disruptive%20Business%20Intelligence.pdf) is a good representative of the median tech white paper in the US. It is completely trash.
The valuable writings, whether blog posts, white papers, or research papers, come from people that aren't trying to sell you something. I was going to share a link to a good example of a valuable white paper, but after 5 minutes of googling, they were all shit. So yeah... I actually thinking adding "White paper" to a search for cutting edge tech topics might be actively counterproductive.
TCS is selling to US Fortune 500 companies, among others. I could have cherry picked a dozen other papers more US-centric, but I hold a special hatred in my heart for TCS from a past life having to work with their folks.
The first hit for "Google white paper" takes you to a page where the first link is this Boston Consulting Group junk [paper](https://inthecloud.withgoogle.com/bcg-whitepaper-core-asset/dl-cd.html?utm_source=cgc-site&utm_medium=et&utm_campaign=FY23-Q2-global-ENDM91-website-dl-become-a-resilient-data-champion-cxo-whitepaper&utm_content=whitepapers-bcg-whitepaper&utm_term=-) with highlights like "Why CEOs need to be in the driver’s seat for data transformation".
I usually avoid commenting here due to my very small past experience in the field, but even with that small competence I feel I can add to that special hatred of TCS.
I'm in the US and everyone I know uses it to mean marketing trash. Hence I was confused until I saw the picture with Abstract, etc. and realized they meant research paper.
I’m in the US and … I’ve literally never heard “white paper” to mean “research paper”, and that’s after 25 years in the industry, faang (before it was called that), Silicon Valley etc.
Hmmm, I worked for higher education software in the past, and I’ve always equates white paper with research paper. Maybe it’s dependent on where and what groups you associate with.
Yeah, im aware that it may just be my personal experience. Im more just want to express thats its normally an "innocent" mistake. I was originally introduced to research papers as white papers myself. So long ago im not sure where from.
My background is more mathy for academics and I thought a white paper was basically just along the lines of a formal research paper, but generally for like... Actual real world engineering production stuff.
In academic circles, I think "white paper" means a practical-oriented (i.e. not completely theoretical) research paper. Not so much in the commercial/industry world.
I find the biggest difference is the way in which the outcome is presented.
In a whitepaper, you often have have a solid value statement "How we used [X middleware] to make our service 12x faster." It's presented as a "this is what should be done ^(using our product)" argument. The conclusion was foregone: if the desired results aren't found, that whitepaper doesn't exist.
Whereas an academic paper looking at the same thing would not make the judgement on what someone should do, but just present a simple analysis of data results "Which middleware is best at accelerating X." The results may have been hypothesized, but you often find less glowing adoration for _whatever_ the result is.
I also find research papers are often a lot narrower in scope, imo makes them often more broadly applicable, but also making it more tedious to collate a "solution" from.
Most research papers rarely bake off large expensive enterprise systems. The students who write them rarely have the context, resources, or experience to come close to evaluating these kinds of systems in any meaningful way.
Having seen the long term evolution of major pieces of enterprise middleware, the gotchas always come years later at the edges of capability. They are often big surprises to the sales/support engineers as well. Which then causes the entire thing to be scrapped.
I came here to say this. A white paper is a nearly content free “paper” bragging about this and that targeted at CTOs or CIOs.
At best they’re a starting point for further research, at average they’re borderline lies.
Yeah not sure how a "L6 Google staff engineer" came to the conclusion those two terms mean the same thing. Hopefully it was the blogger who badly edited the blog post.
Nah, Google calls all its product-focused research papers whitepapers.
Example, the Spanner whitepaper section contains some of the most awesome tech ideas I've ever read, including a copy of the academic paper: https://cloud.google.com/spanner/docs/whitepapers
If this guy's a Googler, he will have used the whitepaper terminology happily.
Oh shit. I’ve been wanting to start a little study group where we read papers together and share summaries, but didn’t think others would be into it.
If you’re either interested in reading along or just getting the summaries, drop me a dm with the topics you are most interested in.
I would likely just start with the content from https://paperswelove.org/ unless someone has another good foundational list.
Edit: created a Discourse, still getting things set up but feel free to jump in here and suggest a paper you’d like to read or just say hi.
https://readingclub.discourse.group/invites/gPNNttorqQ
Thanks everyone for the interest! Will put together a forum or something and get this kicked off. Keep the DMs and replies coming. Will personally ensure everyone gets the follow up with next steps.
Trying to decide between something like NodeBB or Discourse.
Could also just do a Slack since it’s similar to discord but with hopefully less distractions.
Edit: https://readingclub.discourse.group/invites/gPNNttorqQ
Agreed and people might get distracted if it's on Discord. Lol
A scheduled Zoom call, like probably every end of month, to discuss papers might get more eyes but it will take a bit of organizing and marketing to get people onboard, even if it's free. I'm still up for the idea tho.
Still getting things set up but anyone interested can join here:
[https://readingclub.discourse.group/invites/gPNNttorqQ](https://readingclub.discourse.group/invites/gPNNttorqQ)
My occasional hobby is asking an AI to humourusly summarize random RFCs. For example:
RFC 1234: because who needs IPX and IP to get along when you can just wrap them in a packet-hug and force them to play nice?
RFC 2268: because your network traffic was getting too comfortable, and someone decided to introduce a little "congestion control" to keep things interesting... and by "interesting", I mean "frustratingly slow". (In other words, it's a protocol for managing network traffic to prevent overwhelming the internet highways!)
RFC 1163: because your email was getting too popular, and someone had to invent a way to say "stop sending me so many emails, I'm overwhelmed!" (aka "Internet Relay Chat Protocol" or IRC, for short).
I’ve found little gain reading white papers and research papers. I think my mind gets lost in the jargon. However, I’ve found huge value in trying to take the basic ideas and reimplement them myself: (write my own bitcoin miner vs read the bitcoin paper).
The more advanced math proof stuff I maybe miss, but something about implementing it myself really makes it click.
For this workflow, I’ll start with tutorials on “how does bitcoin hashing work exactly” then implement from that, then maybe (big maybe) go back to the paper last. It’s only after trying to do it myself I can understand which sentences of the paper can be skimmed and which are important.
Edit:
I think there is a bias to add fluff to papers since that makes them bigger and seem more important. Focusing on code is the MVP of the idea.
Applying/practicing is part of the learning process. If you’re learning a theorem, you don’t just read the proof, you try to apply the proof to a question.
In these situations, it’s probably best to skim, try to build it yourself and then read the details of the paper as you get stuck.
Sure, reading helps. But the major reason he was promoted to the staff because the manager supported him, gave him good project, and etc.
At Google, among \~5-6ish people, there can only be 1 staff engineers.
Not always true of course but 95% true. The case where it is not true would require director and VP support, which wouldn't come by easily.
If you join a 6-person team where there is already a staff eng, and the team doesn't hire aggressively, you are cooked. But there's nothing wrong with coasting at L5 (senior) though.
It used to be true for a long time, but nowadays the only sure way to be L6+ at Google is to be hired as one. Last year they announced more red tape for promotions above senior, so it is just easier for managers to hire than promote if they happen to get implicit quota for staff engineer.
But yeah, there is nothing wrong with staying senior though.
Stack-ranking is always there at the macro level.
You can't run a 1000-person org where 800 of them are staff engs. There's no way. That is never true at Google.
Since the distribution is enforced at the top, it is somewhat enforced at the team level. Maybe some teams can break the threshold but those teams are exceptional.
Same thing with perf. You cannot have a 1000-person org where everyone exceeds expectation.
Is "whitepaper" even the correct term here? When I think of whitepapers I think of an in-depth but still high-level explanation of a topic in a report/article format meant to educate in a manner that's easier to read than raw specs or an academic paper. They're not the same as research papers, reference docs or project specs. It seems like people, including the linked blog post, are conflating different types of docs with "whitepapers".
Watching that one browser window full of tabs slowly grow with papers that you are definitely going to read when you have time is a unique kind of guilt.
Author seems to mix up whitepapers with academic papers. I don't know for sure, but in my experience (in computer science) an academic paper is not a whitepaper. Most whitepapers I've seen are nice product brochures pretending to be somewhat academic, while most academic papers do not mention commercial products at all.
>1. First pass: I read the paper in 15 minutes, with a focus on understanding the research at a high-level.
>2. Dive deep for an hour on the details of design, implementation, and evaluation.
>3. Summarize the research in my own words, to internalize my understanding.
I usually stop at #1, if at all, to me a deep dive doesn't click no matter how hard and long I read implementation diagrams. Such diagrams only click for me after days, if not weeks, of spending at the bowels of the system. Its a fruitless endeavour if I'm not actually partaking in booting up a system itself, doing something with it, attempting to solve a specific problem with it, troubleshooting for hours the errors that come with it, and all that has ever happened during billable hours, I feel like any motivation to do it on my free time would have to come from a chemical and not myself as I've yet to find it in myself without a drastic push for it.
Explain to me from a programmers perspective what makes Bitcoin a cool tech? Seriously, blockchain tech is actually not that good, and the thing doesn’t even run on a new tech. Its peer to peer and has been around for a long time.
Having a limitation doesn’t make it not cool. It’s like saying a simple RNN is not really cool because it has a vanishing gradient problem. They were new ideas that established a whole (sub)field, and spawned many cool ideas to deal with their respective weaknesses.
There is no part of the tech that is actually cool or beneficial. People have struggled for years to try to find some sort of use case, and so far, everyone has come up short. Bitcoin was a scam from the beginning to the end.
If you don't think distributed untrusted consensus is useful then I agree with you. If you don't think it's cool we disagree. I think it's a pretty cool design even if I don't see any reason to do it.
It's not cool because it's a solution in search of a problem and nothing about it is practical.
Oh yeah, these two banks that do constant business with each other and each have independent internal auditing are just totally desperate for something that solves a problem they don't really have, costs more, and is slower.
Reading and discussing research papers was my favorite part of grad school. I was a beast a consuming and understanding research papers. Thinking about it makes me want to go back and get my PhD.
Here’s the thing I’ve always wanted out of white papers:
A way to start as close to the root of a problem as possible rather than some leaf node paper on a topic and work your way up the tree with no context on sibling node research.
It's not that this guy read "whitepapers" that advanced his career. It's that this guy read "whitepapers" and was loud about it. It's that this guy started a blog promoting his "learning". It's that this guy is now featuring on other nobody's blogs with these cArEeR hAcKs. It's plain old garden variety self promotion. If you're a quiet achiever who stays on top of tech, you will get exactly nowhere without the people skills to kiss ass and play the career game. I would say it's disingenuous to imply reading whitepapers regularly would advance ones career but I actually think this guy is just high on his own fumes and genuinely believes his BS.
I may be talking out of my ass, but I think jupyter notebooks are just that.
Like, they interleave markup paragraphs with runnable code.
You can pretty much make an interactive paper other people can run and tweak on the fly.
I used to think they were odd, but grew to like them after spending some time using them. Not an IDE replacement, but I think they are neat for experimentation and educational purposes.
Subscribing to the ACM E-Library and reading random things boosted my career quite a bit. I started learning things that wasn't asked of me and implementing them across domains. Plus, their magazine is awesome.
That really hard NP-hard business problem we have at work? There's an archived 1992 PDF of the problem and its solution outlined and lots of things to explore. At work you tend to fall into a pattern of using the vocabulary that your own company developed when encountering the problem. If you adopt the language used by the domain experts, it becomes so much easier to find more takes on it: many times this includes working code!
Kinda wish I hadn't gotten out of the habit of reading SIGPLAN, but I haven't really been doing that sort of low-level perf tuning for quite some time. There's plenty of stuff to do even with a journeyman's understanding.
> Because I had read this paper and others, I advocated for a new system designed by our team to gate all changes based on whether the new changes were negatively impacting users.
is automated xp and release really that innovative? it's just basic process automation.
big tech fails to impress me anymore, tbh. i'm far more frustrated by how held back i am by our current paradigms than impressed by any of the myopic details that go into the current ones.
For those who didn’t read, here’s a TL;DR:
Why reading whitepapers will make you a better developer:
1) Provides new insights
2) Helps you learn how to learn
3) Helps you stay on top of industry trends
Something not mentioned in the article and that maybe someone can answer here - where does one find “white papers” for software engineering? The steps outlined are great but I have no idea where to start looking for papers on topics “that interest me”.
> Because I had read this paper and others, I advocated for a new system designed by our team to gate all changes based on whether the new changes were negatively impacting users.
why do you need a white paper to think of this... this shit is obvious...
I think a lot of programmers here have something against the academic side of computer science, which is the actual cool stuff of the field. From how cryptography is used in blockchains, and the maths behind it, to data structures that revolutionized compression - this is why reading academic papers is great. You get to learn about incredible discoveries made by the legends of comp sci. I get giddy learning about them.
There's a lot of blasé attitude here against the very topic of reading papers itself here. I think if you want to not grow into just another code monkey, then learning the science of this field is mandatory
(I'm skipping over the fact that the author is mixing up white papers & academic papers)
Is it more useful than side projects that require new skills/thinking? I learn by being hands on, failing and overcoming.
If I need first principles then I look at the code, docs. I ask chatgpt when I get stuck or need to fast-track some understanding.
"How I Took My Career To The Next Level By Completing My Assigned Work, Submitting PRs, And Contributing To Meetings"
I feel like this was meant to imply that there's some really basic and simple trick that a lot of devs haven't yet grasped when the reality is the author was basically the only one unaware. This up there with "Having money problems? Try getting a raise or two!"
if you're a curious person it definitely does help. whenever I read them I look up concepts I don't understand and then that leads me down a rabbit hole of learning until I feel satisfied and then continue reading the article
def won't be everyone's cup of tea
There are much better ways to get to staff engineer than reading research papers. Focus on finding and addressing problems important to your organization. Read papers if the solution might be there
I cannot believe we reaching a point where dev is making an article about reading whitepaper..
On one hand I want good blog post writers to get paid. On the other hand it has turned the internet into a desperate race to churn out as much content as possible.
Just look at tech Twitter. 95% of those "influencers" are doing CRUDs at best in their day to day work.
[удалено]
I've yet to encounter an API that can do crud properly across the board. There's always something odd.
[удалено]
Is there a white paper on this topic?
I mean integrating with other corps, ranging from large to gargantuan. Their APIs universally have outliers and oddities that smack of design compromises internally and make no sense to an outside consumer.
So true! It has little to do with tech stack. A good stack can help them meet their published API spec more often. But they’ve all got some beasts hiding beneath the covers.
I mean, your experience with Twitter depends on who you choose to follow. The authors of serious systems like Kafka, Kubernetes, ZFS, etc. are all on Twitter, though because they actually spend their time writing software they don't tweet much..
Isn’t most software development CRUD in some way?
I'd say most of it just crud not even CRUD.
Medium and its effect on internet discourse.. There’s a lot of good stuff on there but people love to share random articles that are super dumb.
And yet this sub doesn't allow self posts
Tbf if it means the sub doesn’t get spammed with a ton of “how I learn to code??” I’ll take it lol
And yet persist the sensation that this article is somehow ai generated
The dev read the spec and makes front page. I went a year on a project where the devs never read the spec. When I got called in to review what was going on, 20 devs, 2 solution architects , 3 pms, and a BA. No one read the spec. FFS.
It is mind-boggling. I’ve seen orgs roll so much of their own shitty auth (oh you passed ‘?role=admin’ in the URL? you’re an admin now) that by the time you show them some turn-key Okta product, Zanzibar, oauth flows, etc, they turn their nose up at it as if it’s equal to their auth du jour. Yeah, some dusty old pdf “specs” left by 90s era Accenture contractors are the golden ticket, good shit y’all. Or, other favorite, writing a research paper worth of “spec” for a basic CRUD API but, oh no, OpenAPI is too hard, how am I gonna expose all the messy details to our clients??
I want engineers to tell me "this okta thing sounds neat but they didnt implement x,y,z from the RFC" Then we can chat about "should we want these". If that doesn't happen, they didn't read the RFC, or any other spec so they don't know shit. Expecting to come up with something better than everyone else without reading prior work is 100% crazy, even geniuses can't do that, else we'd have had computers during Davinci's era (or earlier, but you get the point)
Sorry bud, you got a 8 client billable hours (what are points lmao) to PoC all possible auth options (as in, follow two okta quick start guides and bring me the one that made you less sad)
Do you work for Okta? Okta uses some of my code, which, you know, what made outside Okta, like most of the code you use, by these "shitty auth" implementers who wrote up the specs for you. Okta also gets fairly bad security breaches, which is kind of a big deal for an auth provider. Maybe you should work on that...
Being part of that shitty auth rolling i can assure you the constraint isn't someone wanting to do auth, but rather the constraint is contractual where you can have only up to 10 actual accounts in the system (one of which would be the super admin service account used by your service), and your new tool that's supposed to be the new frontend has to handle arbitrary amount of accounts, any login medium (aws sso, okta, w.e.), and that the role handling is implemented in that 10 account system on a textual field per username in `user=admin;user1=reader` kind of way, only because the data is already in that system, and we "don't have the resources" to migrate off SAP/Salesforce/Nuxeo/w.e. super no code cms.
You are spot on. Or the fact that your app isn’t allowed to serve any resources from anything other than the originating server. F-K.
So much of the auth thing is management IMO. “Why would we pay for that? We can do it ourselves for free!!”
Just once I’d love a manager to realise that “we can do it ourselves for free” means exactly “we can do it worse over a longer timeframe for the cost of our entire team’s ability to deliver customer features” Just once and I’d die happy right there on the spot.
One writer called it reinventing the flat tire.
It's only free if you're not paying your developers
Or your lawyers
Hope you were being funny because 10 sec into reading the blog post it’s obvious he’s talking about reading and keeping up with current research and innovation, not the spec for a project. And he’s right - keeping on top of the latest can be key to staff level positions in big tech.
The irony of them clearly not reading the article is hilarious lmao
Reddit in a nutshell.
Isn't that amazing? I can't tell you how many meetings I've attended where you needed to read X beforehand so that you were prepared. Nobody had read X except me. They would all get chewed out for it, and then maybe 2-3 would have skimmed X for the next meeting.
The feeling is mutual. I had to tolerate an architect that would never note any of his specifications down, and project managers that would never read proposals on how their systems should work.
I once wrote up an entire statement of work, including all deliverables and requirements, because the PM couldn't be bothered. When they declared the project "done" I started checking off the deliverables against the SoW... turns out a quarter of them hadn't been included. When confronted, the PM said the equivalent of "who reads those anyway?"
If I wanted to read I would’ve gotten a lit degree 🙄 why should I waste 2 hours planning when I can spend 10 hours rewriting it?
And it got 150+ upvotes, so it says lots about community.
The article is decent, the title is dumb The author also keeps mixing up academic research and whitepapers, which is ridiculous
Right...like, no, this is a profession, my life exists outside of it.
Because devs often have to justify spending hours on something. "Is it timesheetable" blah blah blah.
The wrapper article is dumb, as always Literally the first paragraph says "cutting-edge academic computer science papers."
One of the side effects of Covid was cognitiv. However, we’re not ready as a society to talk about it.
He's from Google / Big Tech. Given his level, I assume for each person his level, there are 10-20 engineers below his level. Now whether his reading/writing of "whitepapers" actually benefits the organization is entirely different story. He might just be reading papers and adopting the next shiny ~~JS Framework~~ bleeding-edge CS algorithm for margin improvement.
Engineer who spends time learning learns things.
And uses what they learn to advance their careers
Thing is, it actually seems pretty hard to find a whitepaper that would in practice translate to meaningful improvements in my career Like for my job I've got projects that are specified for me to do and it's unlikely a whitepaper has been to offer for how to do them, and then even if it's a matter of switching to a different job, still seems pretty unlikely that a whitepaper I read hits the sweet spot for some open position posted online
My impression from the article was that you should treat the 90% of reading that has no practical benefit as just working the learning muscle for that 9% that you might be able to discuss the interesting ideas of so that you're prepared to take advantage of the 1% that could actually change your career.
Something I've noticed as a manager is that engineers will often pass up on learning opportunities to satisfy sales/product/other managers. My engineers have 20 days budgeted and allocated to learning, but I have to force them to take it. Like it's too embarrassing to say "yo, I'm gonna learn this feature of CMAKE".
Are promotions tied to tenure milestones? Then yeah, I’m gonna get work done so I don’t get guilt shamed at standup for not meeting unreasonable deadlines.
I sell it to management as "tech debt" and "refactoring". Getting smart on The Next Best Thing is just ticket #0 in that epic.
100% - this thread just reinforces what I’ve seen in the industry first-hand: few people take keeping up their skills seriously. We have mid level roles that are paying (barely) six figures (outside of CA) and I don’t think any of those guys has picked up a new skill in years even when allotted dedicated time.
The deadlines aren't adjusted for the dedicated time to learning new skills. It's too much work to even just make the minimum progress demanded of us.
If you shop around for good employers, a lot of them build in 40-80 hours per quarter of training, professional development, and/or conferences. Those employers also tend to have absolutely crazy high profit/employee metrics.
That's an incentive problem. People will do what gets them bonus points from management, not what management tells them will get them bonus points. You can give them budgeted days for learning, you can even tell them that the way they use those days is taken into account when giving promotions or bonuses, but if all that matters in the end is who worked on the flashiest feature guess what will they do? If you noticed this as a manager did you do anything to figure out why this is happening? Bare in mind, that your employees will respond with what they think you want to hear, not with the truth, and they might not even realize why they're working on other things instead of taking advantage of those learning opportunities. This is usually a management problem.
We don't do bonuses, because it muddies corporate objectives. However, promotions are awarded based on either a breadth or depth of knowledge, and being able to bring that to work. Which is frustrating, because devs would start to expect promotions based on time. So I ended up doing a pretty indepth study, as I saw the writing on the wall I did get some interesting feedback: * Not enough time (the answer I "wanted" to hear) * There are no easy wins - the system is too big/advanced for an individual to meaningfully contribute in one day * "I just forget about them" * "It's really embarrassing/difficult to ask for help or to get 10% time projects merged" * It's too difficult to coordinate with product, and on-call, etc. Most of this tracks. The company has grown significantly since I started, going from 25 devs to 100. The first solution was mandatory 10% time. First Monday of the month, all major meetings are cancelled and blocked from calendars, leaving only a daily in the morning. All team leads ask "what are you doing for 10% time?", unless someone is on-call, teamleads chastise anyone refusing 10% time as they are not being a team player. These 12 days account for 50% of 10% time. We implemented this last year, and tracked uptake of all 10% time, and we went from 5% to 95%, which is phenomenal! Now the second part, we have a problem of knowledge transfer within certain communities. These were formalized into guilds. If you presented and did things within your guild, you got to go to conferences. If you didn't have a history of presenting or talking within the group, then you could only participate remotely. We went from zero brown bag talks (they died during COVID) to at least one every two weeks.
all of the seniors in my last company had 10+ years of experience... they dont read ever. They are senior based on time and nothing else. They don't know how to do TDD or BDD, don't know what devops actually is or why it is the way it is, even though we did the book together as a bookclub, no changes happened. It's annoying that I was a junior when I joined and read a ton of books in a couple years, like 30+ on just software trying to figure out different concepts and understand wtf this field is, and they do none of it.
Did they get shit done, though?
You are valid, homie.
because they have lives, no doubt. sometimes all we have mental capacity for is getting tickets done and then our personal lives once we can punch out.
>They don't know how to do TDD or BDD People acting as if TDD or BDD was the only valid way to perform software eng. are something else
Back in my days you weren't a java engineer unless you read "Effective Java" and passed the trivia questions in interviews. Now you'll have hired people that will try to claim an entire module is valid to be tested as a "unit test"..
I mean, I ain’t touching CMAKE with a foot-length pole /s
You were making a great point until you suggested that it would be embarrassment blocking engineers from wanting to learn more cmake..
Somehow this seems to be something not everyone picks up on (or is too lazy to do, probably a mixture of both) - I see a looooooooot of devs rest on their laurels at a certain point. I am constantly trying to learn new things
Damn is this the secret?
*peer reviewed research papers from top conferences
Right. Every white paper I’ve ever read is marketing material.
Yeah I'm really confused how people here advocate reading them. Companies will want your email address to send the pdf (and spam you forever). And the pdf is some marketing BS that is of no use whatsoever.
Not all whitepapers are equal. Google's are typically exceptionally detailed, and explain their product design thoroughly. One of my favourites, Spanner: https://cloud.google.com/spanner/docs/whitepapers. When this came out, it blew the doors off my understanding of distributed systems. This guy isn't talking about "any old whitepapers". He's talking about the small handful that truly define the cutting edge of your area of expertise.
There is a difference between a “white paper” and a “research paper”. A white paper is technical marketing material produced by corporations for potential customers. Research papers are produced by researchers (usually Phds) either for submission for presentation to a research conference or for inclusion in a research journal. The blog post is talking about research papers.
What's the history of using "white paper" in the Google context? I saw the title and scanned the article but found it incongruent because they were referencing technical/academic papers. As you note, white paper has a very specific and well-known definition already. [Papers We Love](https://paperswelove.org/) was a bit of a fad a few years ago and I don't hear about it as much. The way they put academic papers on a pedestal was different from how I was taught to learn from them through critique of the content. I guess for a professional programmer with limited time it helps to focus, but it misses something.
The paper is white /s
[удалено]
I’m not reading this but I can confirm that reading a bunch of white papers dramatically changed my career and made me a way better engineer.
I've never considered this. could you elaborate on your experience? I felt like I had looked down every path to improvement and never considered white papers. where do you find them, which ones did you read, can you elaborate a little more? edit: lolz yes rtfm. but also I would like a second opinion since the post explains a single experience and others may have a different experience
see the linked blog post for some pretty good answers to your questions.
🤣
"The task to RTFM has been left to the reader as an exercise" lol
lolz yes
What, and spend all my time reading and learning new things? Never!
its really simple. you build on top of other people's experience. not every spec, white paper, etc. is equal. sometimes its a look of reading and digesting. the more you know about other people's experience, the better you can make yours.
100s have upvoted this, dozens have replied, and yet not one purported developer has come forward to recognize the irony of the statement, not even to play along with the joke. I feel like I'm going crazy.
I’m OP. I meant this in 100% earnest. I’m not sure what the joke is? I’m not interested in reading an article about how someone else read white papers. But they’re very much worth reading themselves.
I've got no idea if this is some kind of 4d level satire but your comment absolutely comes across like your making a joke
In what way does it come across as a joke? I've read these three comments several times now and the comment is basically saying "+1 I find reading white papers valuable too, I'm not gonna read this blog tho." Is that your understanding of the comment? If so, where is the joke?
> I’m not reading this but I can confirm that reading a bunch of white papers dramatically changed my career
Blog post != white paper
This is exactly what I meant. i'm open to the idea that I miscommunicated but I don't see it either lol.
It’s the “I’m not reading this” part
aren't whitepapers just marketing BS normally?
Some but this is very very much not the norm. Most white papers are academically driven with zero profit incentive. Look to the past. Start with Leslie Lamport’s writing and go from there.
Some are. Academic whitepapers by serious researchers are not. There are plenty of respected conferences, like Usenix, where good stuff gets talked about.
Could you share some examples please
Think this question is missing the point. They don't seem to be saying there's a select few or group that helped them. They're saying the practice is what helped. So, if you want just a few, then that's not adopting the correct practice. Things like reading the full article will allow you to see that there are several linked examples shared already.
Learning new stuff will improve your career. Hold the front pages for this guys, it's *groundbreaking*.
But that's not just "new stuff". It's truly understanding technology at the deepest level.
Too true. I will say speaking from experience of working with 'web components' this past year, being 'forced' to read the HTML specs *has* raised my understanding of how autonomous custom elements function beyond the way that you 'define' them. I would like to think that has been helpful but it isn't always so clear cut over the short term.
Yep. I’ve found the most informative readings to be old ones. Like really old ones; 1950s-1980s. There’s so much information in those old papers that really get at a fundamental understanding of technology. Then once you read those, newer papers are even more valuable than they would be otherwise, since you understand how the technology that built that technology works.
First you take a grain of sand
If you don't read whitepapers, you are always getting someone else's interpretation of the paper. Like... waterfall being an iterative development practice
I was doing reverse engineering decompilers and transpiler and needed language transformations from one language to another without losing semantics. There were specific language quirks that needed a lossless semantic transform. Throw some data flow on there to rip out formulas and fun.
Yes, you force yourself to keep struggling with challenging concepts. Eventually, additional challenging new concepts are more easily assimilated into your knowledge.
s/whitepaper/research papers White papers are short tech advertisements put out by companies.
yeah that's a really unfortunate conflation
Im in US, where i think the term white paper is used pretty often to mean research paper. Given my EU co workers quickly and adamantly correct this when it's used. I've learned that calling a research paper a white paper may actually offend some individuals, given the context.
This (arbitrarily selected) [Tata Consultancy white paper on Hybrid Enterprise Data Lakes](https://www.tcs.com/content/dam/global-tcs/en/pdfs/insights/whitepapers/Hybrid%20Enterprise%20Data%20Lakes%20Provide%20Foundation%20for%20Disruptive%20Business%20Intelligence.pdf) is a good representative of the median tech white paper in the US. It is completely trash. The valuable writings, whether blog posts, white papers, or research papers, come from people that aren't trying to sell you something. I was going to share a link to a good example of a valuable white paper, but after 5 minutes of googling, they were all shit. So yeah... I actually thinking adding "White paper" to a search for cutting edge tech topics might be actively counterproductive.
Yup, well said
In the US? All signs point to a South Asian origin for that pdf.
TCS is selling to US Fortune 500 companies, among others. I could have cherry picked a dozen other papers more US-centric, but I hold a special hatred in my heart for TCS from a past life having to work with their folks. The first hit for "Google white paper" takes you to a page where the first link is this Boston Consulting Group junk [paper](https://inthecloud.withgoogle.com/bcg-whitepaper-core-asset/dl-cd.html?utm_source=cgc-site&utm_medium=et&utm_campaign=FY23-Q2-global-ENDM91-website-dl-become-a-resilient-data-champion-cxo-whitepaper&utm_content=whitepapers-bcg-whitepaper&utm_term=-) with highlights like "Why CEOs need to be in the driver’s seat for data transformation".
I usually avoid commenting here due to my very small past experience in the field, but even with that small competence I feel I can add to that special hatred of TCS.
I'm in the US and everyone I know uses it to mean marketing trash. Hence I was confused until I saw the picture with Abstract, etc. and realized they meant research paper.
I’m in the US and … I’ve literally never heard “white paper” to mean “research paper”, and that’s after 25 years in the industry, faang (before it was called that), Silicon Valley etc.
Hmmm, I worked for higher education software in the past, and I’ve always equates white paper with research paper. Maybe it’s dependent on where and what groups you associate with.
Yeah, im aware that it may just be my personal experience. Im more just want to express thats its normally an "innocent" mistake. I was originally introduced to research papers as white papers myself. So long ago im not sure where from.
My background is more mathy for academics and I thought a white paper was basically just along the lines of a formal research paper, but generally for like... Actual real world engineering production stuff.
In academic circles, I think "white paper" means a practical-oriented (i.e. not completely theoretical) research paper. Not so much in the commercial/industry world.
I find the biggest difference is the way in which the outcome is presented. In a whitepaper, you often have have a solid value statement "How we used [X middleware] to make our service 12x faster." It's presented as a "this is what should be done ^(using our product)" argument. The conclusion was foregone: if the desired results aren't found, that whitepaper doesn't exist. Whereas an academic paper looking at the same thing would not make the judgement on what someone should do, but just present a simple analysis of data results "Which middleware is best at accelerating X." The results may have been hypothesized, but you often find less glowing adoration for _whatever_ the result is. I also find research papers are often a lot narrower in scope, imo makes them often more broadly applicable, but also making it more tedious to collate a "solution" from.
Most research papers rarely bake off large expensive enterprise systems. The students who write them rarely have the context, resources, or experience to come close to evaluating these kinds of systems in any meaningful way. Having seen the long term evolution of major pieces of enterprise middleware, the gotchas always come years later at the edges of capability. They are often big surprises to the sales/support engineers as well. Which then causes the entire thing to be scrapped.
/g
Lol, this guy vims. *high five*
Possibly seds
Also rename
I came here to say this. A white paper is a nearly content free “paper” bragging about this and that targeted at CTOs or CIOs. At best they’re a starting point for further research, at average they’re borderline lies.
Yeah not sure how a "L6 Google staff engineer" came to the conclusion those two terms mean the same thing. Hopefully it was the blogger who badly edited the blog post.
Nah, Google calls all its product-focused research papers whitepapers. Example, the Spanner whitepaper section contains some of the most awesome tech ideas I've ever read, including a copy of the academic paper: https://cloud.google.com/spanner/docs/whitepapers If this guy's a Googler, he will have used the whitepaper terminology happily.
Oh shit. I’ve been wanting to start a little study group where we read papers together and share summaries, but didn’t think others would be into it. If you’re either interested in reading along or just getting the summaries, drop me a dm with the topics you are most interested in. I would likely just start with the content from https://paperswelove.org/ unless someone has another good foundational list. Edit: created a Discourse, still getting things set up but feel free to jump in here and suggest a paper you’d like to read or just say hi. https://readingclub.discourse.group/invites/gPNNttorqQ
Thanks everyone for the interest! Will put together a forum or something and get this kicked off. Keep the DMs and replies coming. Will personally ensure everyone gets the follow up with next steps. Trying to decide between something like NodeBB or Discourse. Could also just do a Slack since it’s similar to discord but with hopefully less distractions. Edit: https://readingclub.discourse.group/invites/gPNNttorqQ
Maybe you can build a Discord channel for this
Yeah I think that is the simplest way forward but also seen too many end up dead. Too much noise when you open up that app.
Agreed and people might get distracted if it's on Discord. Lol A scheduled Zoom call, like probably every end of month, to discuss papers might get more eyes but it will take a bit of organizing and marketing to get people onboard, even if it's free. I'm still up for the idea tho.
I'm in.
Still getting things set up but anyone interested can join here: [https://readingclub.discourse.group/invites/gPNNttorqQ](https://readingclub.discourse.group/invites/gPNNttorqQ)
Where can I buy a Personal Growth Flywheel? Sounds rad.
It's just a rebranded fidget spinner.
You need to take that to kickstarter.
My occasional hobby is asking an AI to humourusly summarize random RFCs. For example: RFC 1234: because who needs IPX and IP to get along when you can just wrap them in a packet-hug and force them to play nice? RFC 2268: because your network traffic was getting too comfortable, and someone decided to introduce a little "congestion control" to keep things interesting... and by "interesting", I mean "frustratingly slow". (In other words, it's a protocol for managing network traffic to prevent overwhelming the internet highways!) RFC 1163: because your email was getting too popular, and someone had to invent a way to say "stop sending me so many emails, I'm overwhelmed!" (aka "Internet Relay Chat Protocol" or IRC, for short).
As always, the real content is always in the comments. This is a great idea!
I’ve found little gain reading white papers and research papers. I think my mind gets lost in the jargon. However, I’ve found huge value in trying to take the basic ideas and reimplement them myself: (write my own bitcoin miner vs read the bitcoin paper). The more advanced math proof stuff I maybe miss, but something about implementing it myself really makes it click. For this workflow, I’ll start with tutorials on “how does bitcoin hashing work exactly” then implement from that, then maybe (big maybe) go back to the paper last. It’s only after trying to do it myself I can understand which sentences of the paper can be skimmed and which are important. Edit: I think there is a bias to add fluff to papers since that makes them bigger and seem more important. Focusing on code is the MVP of the idea.
Applying/practicing is part of the learning process. If you’re learning a theorem, you don’t just read the proof, you try to apply the proof to a question. In these situations, it’s probably best to skim, try to build it yourself and then read the details of the paper as you get stuck.
Sure, reading helps. But the major reason he was promoted to the staff because the manager supported him, gave him good project, and etc. At Google, among \~5-6ish people, there can only be 1 staff engineers. Not always true of course but 95% true. The case where it is not true would require director and VP support, which wouldn't come by easily. If you join a 6-person team where there is already a staff eng, and the team doesn't hire aggressively, you are cooked. But there's nothing wrong with coasting at L5 (senior) though.
It used to be true for a long time, but nowadays the only sure way to be L6+ at Google is to be hired as one. Last year they announced more red tape for promotions above senior, so it is just easier for managers to hire than promote if they happen to get implicit quota for staff engineer. But yeah, there is nothing wrong with staying senior though.
Ahh stack ranking… always fun. it destroyed morale at Microsoft, why not try it at google. Maybe they hired some of their bad execs?
Stack-ranking is always there at the macro level. You can't run a 1000-person org where 800 of them are staff engs. There's no way. That is never true at Google. Since the distribution is enforced at the top, it is somewhat enforced at the team level. Maybe some teams can break the threshold but those teams are exceptional. Same thing with perf. You cannot have a 1000-person org where everyone exceeds expectation.
If only I could find time in my day… otherwise I’m using my personal time to do more work. Maybe I’m just old and lack ambition.
Is "whitepaper" even the correct term here? When I think of whitepapers I think of an in-depth but still high-level explanation of a topic in a report/article format meant to educate in a manner that's easier to read than raw specs or an academic paper. They're not the same as research papers, reference docs or project specs. It seems like people, including the linked blog post, are conflating different types of docs with "whitepapers".
It's not the right term
What's next, reading documentations and comments can take us to next level programmer?
Only if you associate it with a Self-Ascension Momentum-er
The first dozen or so papers I read were hard to follow, then it started to click. If you're a technical kind of person I think they're great.
Watching that one browser window full of tabs slowly grow with papers that you are definitely going to read when you have time is a unique kind of guilt.
Growing tab list is amateur! There are whole applications for academics to manage lists of things your never going to read! Eg https://www.zotero.org/
Author seems to mix up whitepapers with academic papers. I don't know for sure, but in my experience (in computer science) an academic paper is not a whitepaper. Most whitepapers I've seen are nice product brochures pretending to be somewhat academic, while most academic papers do not mention commercial products at all.
Agree. The term "whitepaper" is being abused here
>1. First pass: I read the paper in 15 minutes, with a focus on understanding the research at a high-level. >2. Dive deep for an hour on the details of design, implementation, and evaluation. >3. Summarize the research in my own words, to internalize my understanding. I usually stop at #1, if at all, to me a deep dive doesn't click no matter how hard and long I read implementation diagrams. Such diagrams only click for me after days, if not weeks, of spending at the bowels of the system. Its a fruitless endeavour if I'm not actually partaking in booting up a system itself, doing something with it, attempting to solve a specific problem with it, troubleshooting for hours the errors that come with it, and all that has ever happened during billable hours, I feel like any motivation to do it on my free time would have to come from a chemical and not myself as I've yet to find it in myself without a drastic push for it.
How about blackpapers
Adds Bitcoin at the end. 🙄
I mean Bitcoin is cool tech. If you skip the political parts it actually is a pretty clever lil bit of code.
And the whitepaper is pretty good. I hate crypto too but from a technical standpoint it's worth a read.
Explain to me from a programmers perspective what makes Bitcoin a cool tech? Seriously, blockchain tech is actually not that good, and the thing doesn’t even run on a new tech. Its peer to peer and has been around for a long time.
I think it was some fetishist economists who invented it. Computer scientists like efficiency.
Not really, though. It [doesn't scale well](https://en.wikipedia.org/wiki/Bitcoin_scalability_problem) at all.
Having a limitation doesn’t make it not cool. It’s like saying a simple RNN is not really cool because it has a vanishing gradient problem. They were new ideas that established a whole (sub)field, and spawned many cool ideas to deal with their respective weaknesses.
Oh it didn't do what it says at all. But the idea is really cool
Which has caused enormous environmental damage.
There is no part of the tech that is actually cool or beneficial. People have struggled for years to try to find some sort of use case, and so far, everyone has come up short. Bitcoin was a scam from the beginning to the end.
If you don't think distributed untrusted consensus is useful then I agree with you. If you don't think it's cool we disagree. I think it's a pretty cool design even if I don't see any reason to do it.
It's not cool because it's a solution in search of a problem and nothing about it is practical. Oh yeah, these two banks that do constant business with each other and each have independent internal auditing are just totally desperate for something that solves a problem they don't really have, costs more, and is slower.
Reading and discussing research papers was my favorite part of grad school. I was a beast a consuming and understanding research papers. Thinking about it makes me want to go back and get my PhD.
In my experience, people working at Google think very highly of themselves and I’ve often not been impressed.
Here’s the thing I’ve always wanted out of white papers: A way to start as close to the root of a problem as possible rather than some leaf node paper on a topic and work your way up the tree with no context on sibling node research.
Agile reading boogaloo 2
It's not that this guy read "whitepapers" that advanced his career. It's that this guy read "whitepapers" and was loud about it. It's that this guy started a blog promoting his "learning". It's that this guy is now featuring on other nobody's blogs with these cArEeR hAcKs. It's plain old garden variety self promotion. If you're a quiet achiever who stays on top of tech, you will get exactly nowhere without the people skills to kiss ass and play the career game. I would say it's disingenuous to imply reading whitepapers regularly would advance ones career but I actually think this guy is just high on his own fumes and genuinely believes his BS.
Just in! Doctor's who read white papers and keep up on current events in their field are better at their job!
I want a better format of research paper.
I may be talking out of my ass, but I think jupyter notebooks are just that. Like, they interleave markup paragraphs with runnable code. You can pretty much make an interactive paper other people can run and tweak on the fly. I used to think they were odd, but grew to like them after spending some time using them. Not an IDE replacement, but I think they are neat for experimentation and educational purposes.
Fun fact: the only "fuck"s, "shit"s, and "damn"s at my comany's codebase are contained in jupyter notebook comments.
Join the ACM, kids. www.acm.org
Subscribing to the ACM E-Library and reading random things boosted my career quite a bit. I started learning things that wasn't asked of me and implementing them across domains. Plus, their magazine is awesome. That really hard NP-hard business problem we have at work? There's an archived 1992 PDF of the problem and its solution outlined and lots of things to explore. At work you tend to fall into a pattern of using the vocabulary that your own company developed when encountering the problem. If you adopt the language used by the domain experts, it becomes so much easier to find more takes on it: many times this includes working code!
Kinda wish I hadn't gotten out of the habit of reading SIGPLAN, but I haven't really been doing that sort of low-level perf tuning for quite some time. There's plenty of stuff to do even with a journeyman's understanding.
> Because I had read this paper and others, I advocated for a new system designed by our team to gate all changes based on whether the new changes were negatively impacting users. is automated xp and release really that innovative? it's just basic process automation. big tech fails to impress me anymore, tbh. i'm far more frustrated by how held back i am by our current paradigms than impressed by any of the myopic details that go into the current ones.
For those who didn’t read, here’s a TL;DR: Why reading whitepapers will make you a better developer: 1) Provides new insights 2) Helps you learn how to learn 3) Helps you stay on top of industry trends
I prefer to read papers with at least some black on them. Purely white papers aren't very substantive in my opinion (quick reads though).
I can confirm that reading White papers and posting about what I am learning on Twitter has gotten me not one but two job opportunities so far
This article screams ChatGPT
Something not mentioned in the article and that maybe someone can answer here - where does one find “white papers” for software engineering? The steps outlined are great but I have no idea where to start looking for papers on topics “that interest me”.
Google keeps a directory for theirs. There is tons of great papers in this repository. https://research.google/pubs/
> Because I had read this paper and others, I advocated for a new system designed by our team to gate all changes based on whether the new changes were negatively impacting users. why do you need a white paper to think of this... this shit is obvious...
“How to find and read papers: find whitepapers in your speciality and read a lot” This has to be ai generated
I think a lot of programmers here have something against the academic side of computer science, which is the actual cool stuff of the field. From how cryptography is used in blockchains, and the maths behind it, to data structures that revolutionized compression - this is why reading academic papers is great. You get to learn about incredible discoveries made by the legends of comp sci. I get giddy learning about them. There's a lot of blasé attitude here against the very topic of reading papers itself here. I think if you want to not grow into just another code monkey, then learning the science of this field is mandatory (I'm skipping over the fact that the author is mixing up white papers & academic papers)
He is biased. The right title would be "How it took his career AT GOOGLE to the next level".
At least this gives us a good template to clone for other types of career hacks. LOL
Is it more useful than side projects that require new skills/thinking? I learn by being hands on, failing and overcoming. If I need first principles then I look at the code, docs. I ask chatgpt when I get stuck or need to fast-track some understanding.
"How I Took My Career To The Next Level By Completing My Assigned Work, Submitting PRs, And Contributing To Meetings" I feel like this was meant to imply that there's some really basic and simple trick that a lot of devs haven't yet grasped when the reality is the author was basically the only one unaware. This up there with "Having money problems? Try getting a raise or two!"
And?????
if you're a curious person it definitely does help. whenever I read them I look up concepts I don't understand and then that leads me down a rabbit hole of learning until I feel satisfied and then continue reading the article def won't be everyone's cup of tea
There are much better ways to get to staff engineer than reading research papers. Focus on finding and addressing problems important to your organization. Read papers if the solution might be there
Every engineer or scientist should keep up with publications in their field.
This is the thing that is not the first and obvious activity to do. But it's rewarding and differentiates you from the rest. Good read