ratww

27 ms·

271.
by ratww 4y ago
Considering the popularity of git itself and the fact it is successfully taught at bootcamps and university at a satisfactory level, I would disagree that being a “deep tool” is part of the reason it’s not 100% ubiquitous. The easy parts ar
272.
by ratww 4y ago
Well, be fair, grandparent argued that a cheat sheet would help "for the first few months", not that it is a "complete solution", so I don't see how my suggestion "proves" anything. Also, without knowing w
273.
by ratww 4y ago
About 90% of the public Youtube spam I see on YT still follows this ultra-simple template: one person asks something on the "top comment", another one replies with a faux-legitimate message. The question is often "does anyone
274.
by ratww 4y ago
Well you can always for help from a co-worker more experienced with Git, or just search the internet for help. That could be a teaching moment.
275.
by ratww 4y ago
Not my experience. I found a lot of hubris in the few last batches of bootcamp devs I interviewed or worked with.
276.
by ratww 4y ago
> creating unnecessary friction for no good reason That's definitely something that most large corporations do.
277.
by ratww 4y ago
Wow. I had erased this from my memory, but: in a company I worked previously, every single string that had to be localised had to go into a JIRA task, after going into an internal localisation tool. Eventually they needed a separate JIRA
278.
by ratww 4y ago
Exactly. In the two restructurings I worked there were lots of people that everyone knew were fundamental to the workings of the institutions. Those people were confident they would stay, and ended up getting amazing raises afterwards so th
279.
by ratww 4y ago
That's actually a great idea. Coupled with a Bone Conducting headphone it sounds like great gear for biking.
280.
by ratww 4y ago
Are the requirements really 19 times harder though? Or at least N times larger, so that it requires 19 times more people? I most sincerely doubt it. The reason there was 19 developers is probably because someone pulled the number 19 out of
281.
by ratww 4y ago
I've worked (as in actively worked) in a couple restructuring efforts, and it went fine, but it wasn't on tech, it was on education. It went massively well. The universities were financially healthier afterwards, and all the remai
282.
by ratww 4y ago
Definitely. JIRA is the case of a product made for buyers/deciders rather than for final users, like the dreaded enterprise ERP. Atlassian's Product Managers believe their product is mostly used by other product managers, but they
283.
by ratww 4y ago
All I really see managers using is the burnup or burndown chart. They seem to choose between up/down based on their current mood. But it doesn't matter which one they choose, it always seem to bring everyone's mood down anywa
284.
by ratww 4y ago
It's kind of amusing: I've seen a few times developers rebelling and moving to whatever other random tool (Atlassian's own Trello, Pivotal Tracker, Github's thing, stickers on the wall) as soon as a hardline PO/PM l
285.
by ratww 4y ago
Yep, agreed. Good observation about operational expenses: management can really fuck things up when it comes to it. But with a large enough company, this might not affect the success. I agree about the "collateral damages" part. A
286.
by ratww 4y ago
I love this example as it hits close to home. I once, several years ago, worked on a team where nobody else knew there was full-text search inside Postgres. Took a few hours to convince, demonstrate and teach, but we got there. Took half th
287.
by ratww 4y ago
> I am of the opinion that a developer should always act like a professional, with the best interests of their employer in mind Sorry but bets are also off once an employer gives them the middle finger, like in this case. If someone is
288.
by ratww 4y ago
Hmmm, I disagree. I also don't think that all managers are morons, but even if they were, the fact is that companies often succeed in spite of managerial issues. Sure, there's lots of people are optimizing for the wrong thing,
289.
by ratww 4y ago
Exactly. The trend to more is often forced by investors etc, but this thinking is also seeping into developers. I worked in a Softbank startup that start hiring like crazy for positions that weren't necessary, because that's what
290.
by ratww 4y ago
Yep. One of the most important books in our field, The Mythical Man Month, agrees with a lot of this. But we still choose to keep ignoring it at our own peril. The part about having one dev doing most of the work is even suggested in the bo
291.
by ratww 4y ago
I'm completely ok with giving a team of 19 developers the benefit of the doubt, but in this case it doesn't matter if they're good or bad developers. They're 19 people. There's gonna be lots more overhead if it&#x
292.
by ratww 4y ago
Also been there. Started on the rewrite, noticed it wasn't gonna go anywhere, asked to switch to maintaining the money maker. Didn't need to refactor much: the code quality was VASTLY superior than the new system. However I not-so
293.
by ratww 4y ago
> To me there is no logical reason for needing 19 engineers other than poor documentation They're rebuilding it from scratch . The documentation needed to build a system from scratch should be provided entirely by management, p
294.
by ratww 4y ago
> The irony is the same companies can pay 3x the comp for external consultants. I once worked for a university during a large ERP migration. There was a mix of employees and consultants working on the migration. Everyone that the unive
295.
by ratww 4y ago
> Fixed budget, no requirements or scope Their requirements were pretty clear to me: they want to have a cake and eat it.
296.
by ratww 4y ago
I can't see why you don't buy it. I have seen this kinda thing happening dozens of times in my career. Both in startups (especially in startups!) but also very frequently even in enterprise. One developer makes a system in N month
297.
by ratww 4y ago
I agree. I tend to use "we" when for the negative stuff of anything that has to be decided by the team ("we changed the code here but it caused a regression", "should we refactor this?"), however I also like to
298.
by ratww 4y ago
I think it really depends. I've seen junior devs getting promotions in several cases because they were that good. On the other hand, I've seen several less performant junior devs that are treated as completely replaceable. This
299.
by ratww 4y ago
GP isn't talking about Pair programming in general. Pair programming is great. But quote-unquote "Pair Programming", where only one person does the work... not really. Been there done that.
300.
by ratww 4y ago
It's not just a plain white shirt. It's a plain white shirt that looks plain for normals, but special for people in the know. With that said, not all wealthy people do it.

More ›