saltedmd5

8 ms·

1.
by saltedmd5 8y ago
The power of DVCS is in that each developer who clones a repository has a fully-functioning local repository complete with history, which can be committed to freely and seamlessly merged into the upstream later. As opposed to the traditiona
2.
by saltedmd5 8y ago
You are wrong. GitHub is a hosting platform for git repositories, which has collaboration tools (such as issue tracking and code review) built into it.
3.
by saltedmd5 8y ago
In the context of the original post, he is referring to origin (the convention for a default remote repository), not master (the convention for a default branch).
4.
by saltedmd5 9y ago
I hope this comment is ironic. Great code should be predictable, obvious and easy to change.
5.
by saltedmd5 9y ago
This is why vertically-sliced product teams work - they minimise the communication and coordination overhead associated with Doing a Thing(TM), while layered or function-specific teams make everything take so much longer - particularly as t
6.
by saltedmd5 9y ago
Yes, but it is also supposed to communicate the point. Which is not always possible in a tl;dr because if it was the author probably would have just written a single paragraph in the first place and saved a whole lot of time for everyone.
7.
by saltedmd5 9y ago
AFAIK rebase always rewrites history. If you rebase your feature branch, you have at least rewritten the history of the local branch even if you then delete it and push to a new remote branch. The trunk will subsequently get a FF merge. R
8.
by saltedmd5 9y ago
Rebase is not simpler in any context - rebase rewrites history, which, if branches have been pushed to remotes, then necessitates force pushes, which in turn breaks any other instances of the same branch. By using rebase to "keep histo
9.
by saltedmd5 9y ago
"I try to keep my git workflow simple," and yet I see 'git rebase' but no 'git merge' in that list.
10.
by saltedmd5 9y ago
I think this is probably the most self-indulgent thing I've ever read.
11.
by saltedmd5 9y ago
The point is that returning an Optional gives you nothing above returning a null - in fact it increases complexity and makes calling code more error-prone for no gain. If your contract says you return a Foo, you could be returning a null. I
12.
by saltedmd5 9y ago
Thank you for calling this out. I have to fight this fight way too often. Optional is really for functional code, not for "eliminating NPEs," because it doesn't do that - in fact it means strictly speaking you have to do add
13.
by saltedmd5 9y ago
Something isn't ironic just because you wouldn't expect it, something is ironic because it is the inverse of expectations. Like if her name had been Lady Smallheart.
14.
by saltedmd5 9y ago
> For simple sites, probably faster to just implement it than find a library and read the docs. Not really - the implementation flow for tools that do this sort of thing are typically: 1. Register account 2. Dump JS snippet into page 3.
15.
by saltedmd5 9y ago
Refrains from pointing out misuse of the term "DevOps".
16.
by saltedmd5 9y ago
This gave me palpitations and then killed my browser.
17.
by saltedmd5 9y ago
The problem is the idea that "layers" and "abstraction" come as a package. You don't need layers to create meaningful and useful abstraction - in fact more often than not they prohibit it. And you certainly don&#x
18.
by saltedmd5 9y ago
The truth is that the construction of CRUD web UIs _is_ 90% automated. The web and storage frameworks do the vast majority of the heavy lifting - the application code is really just simple wiring and validation. The trouble is that (in my e
19.
by saltedmd5 9y ago
> That being said I think there is a minimum level of effort, intelligence, and resilience required to take advantage of certain lucky opportunities if they present themselves. Lucky you for having been born with willpower and smarts, th
20.
by saltedmd5 9y ago
Actually, I think your comment is a simplification: there absolutely is a trade-off between money and satisfaction. That doesn't mean you have to become a starving artist to increase your satisfaction level - just that prioritising x m
21.
by saltedmd5 9y ago
Re: first paragraph - incorrect. The problem with "specs" is that you don't know whether they solve the problem until the solution is implemented and shipped. And even then, you have no real way of knowing what's meat an
22.
by saltedmd5 9y ago
Thing is, the need to formally define "behaviour" like that is a symptom of poor organisational/team structure. If you have multi-discipline teams with end-to-end accountability for a complete product (or vertical slice of a
23.
by saltedmd5 9y ago
Your job as a software developer is to solve problems with code - not to take the thing someone else designed and make it go. That line of thinking just doesn't work. Designing and building software are now the same thing. And that is
24.
by saltedmd5 9y ago
"But software is the spec." This whole discussion can be replaced with this sentence.
25.
How I lost my 25-year battle against corporate claptrap(ft.com)
1 points by saltedmd5 9y ago|1 comments
26.
by saltedmd5 9y ago
A lot of the time it's not even really a compromise. This is why it makes no sense to debate about eventual consistency - the implications are entirely situational. This kind of buzzword is harmful; it leads to overthinking, over-engin
27.
by saltedmd5 9y ago
People who take things literally can't do creative work at a desk?
28.
by saltedmd5 9y ago
This depends on the definition of "right," though - if "close enough" really is enough, then "close enough" _is_ right. "Right" doesn't necessarily mean "precise."
29.
by saltedmd5 9y ago
This is the crux of the problem with a lot of software engineering culture as it stands today - blog posts and talks frequently deliver abstract concepts that only really make sense to people who have already grasped/discovered those c
30.
by saltedmd5 9y ago
> This must be what most people working on a desk must feel like Out of curiosity - as opposed to?

More ›