rckrd

25 ms·

271.
by rckrd 5y ago
Yep. We all start from different starting positions. That makes a big difference early on (what school did this person go to? what have they already accomplished?) and less later on
272.
by rckrd 5y ago
Agreed. It wouldn't be so hard if things were linear. All models are wrong, but some are useful.
273.
by rckrd 5y ago
Two lines to represent the difference between (high slope, low intercept) and (low slope, high intercept)
274.
by rckrd 5y ago
I actually think the advice is aligned with that. Young candidates have high slope and low intercept. I don't think the aim of ambitious young developers is to move jobs and maximize pay, but rather to be in a role where they can conti
275.
by rckrd 5y ago
In my experience, the short run is always longer than we think, but the long run is always shorter than we think.
276.
by rckrd 5y ago
Have you looked at Kubeflow? https://www.kubeflow.org/
277.
Hire for slope, not Y-Intercept(matt-rickard.com)
127 points by rckrd 5y ago|91 comments
278.
One Month of Using GitHub Copilot(matt-rickard.com)
1 points by rckrd 5y ago|0 comments
279.
DRY Considered Harmful(matt-rickard.com)
2 points by rckrd 5y ago|1 comments
280.
Yak Shaving(matt-rickard.com)
2 points by rckrd 5y ago|0 comments
281.
“It's never been cheaper or more expensive to start a company.”(matt-rickard.com)
3 points by rckrd 5y ago|0 comments
282.
Non-Consensus Right(matt-rickard.com)
3 points by rckrd 5y ago|0 comments
283.
by rckrd 5y ago
Thanks for the feedback. I agree, the reverse order probably makes more sense. Distribution is difficult. I think that's more of a marketing issue than a technical one (although just as difficult). Will put that on the list for a futur
284.
A Practical Guide to Growing Your Open Source Project: Part 3 – Users(matt-rickard.com)
5 points by rckrd 5y ago|2 comments
285.
A Practical Guide to Growing Your Open Source Project: Part 2 – Community(matt-rickard.com)
2 points by rckrd 5y ago|0 comments
286.
A Practical Guide to Growing Your Open Source Project: Part 1 – Contributors(matt-rickard.com)
2 points by rckrd 5y ago|0 comments
287.
Service Reliability Math That Every Engineer Should Know(matt-rickard.com)
2 points by rckrd 5y ago|1 comments
288.
Coding Classical Latin(matt-rickard.com)
1 points by rckrd 5y ago|0 comments
289.
by rckrd 5y ago
Good point. If you're writing your own library, maybe. If you're writing business logic mostly, probably not. Thanks for the perspective.
290.
by rckrd 5y ago
Domain Name System - As a developer working on Kubernetes. It's always DNS.
291.
by rckrd 5y ago
Link should be fixed. It's https://www.kernel.org/doc/html/v4.10/process/coding-style.h...
292.
by rckrd 5y ago
(1) Maturity of Kubernetes APIs. Fewer upstream changes. (2) It's one of the main products of a venture-backed company. At Google, at the time, it was tough to get engineers on products like minikube.
293.
by rckrd 5y ago
Software engineering is one of the highest leverage things you can do. Keep it up!
294.
by rckrd 5y ago
I've actually found that knowledge diffusion between different languages and different types of developers can be significant - e.g., game developers work much differently than distributed systems engineers. Not always, but sometimes,
295.
by rckrd 5y ago
Yep, modularity is immensely valuable. Requirements change. Technology changes.
296.
by rckrd 5y ago
Author here, ironically, guilty of this https://matt-rickard.com/virgo-lang/
297.
by rckrd 5y ago
Great idea. Some in-depth follow ups are on my radar (I've been trying to publish 1 post a day, yet, never run out of ideas.)
298.
by rckrd 5y ago
Agreed - tough to nail down a definition of deliberate practice for software engineering. I credit three sources - Working on a large open-source gave me access to high-quality reviewers from around the world. - Likewise, at Google, I was s
299.
by rckrd 5y ago
Agreed!
300.
by rckrd 5y ago
Thanks, fixed!

More ›