julik

16 ms·

211.
by julik 4y ago
Yes, people do care, but if they are not the ones making the purchasing decision (and instead it gets made by someone else who never has to suffer the software themselves) the problem will proliferate.
212.
by julik 4y ago
Well, there is ARRI although I doubt all their parts are locally-sourced :D
213.
by julik 4y ago
With a "single vendor" providing your stdlib (Apple is a good case in point) dynamic linking is actually better. It is also absolutely no fun whatsoever to recompile your entire hard drive when doing development (which is what Rus
214.
by julik 4y ago
The challenge here is that while most businesses assume software is just "produced" once and then earns them money indefinitely, the reality is that there is some amount of "production" that needs to happen afterwards. M
215.
by julik 4y ago
Yes. Note that you are by far not the first person noticing that collaborating with Dave is... challenging.
216.
by julik 4y ago
I was intrigued by the title of this article and if I remember well Atom was a sensible standard that was quite well defined, but specifically Dave Winer didn't want it to happen because it was not invented by him. I switched all RSS-y
217.
by julik 4y ago
Easy to debug and write well-tested - mostly yes. Composable is tough though (make sure all your table aliases are unique, that there are no unambiguous column names, that all your ANDs are in place and don't forget that 1=1 to make it
218.
by julik 4y ago
In short: if you have a meaningful recovery pathway for a particular exception this can be useful, but I found that 9 out of 10 exceptions/errors in code cannot be recovered from. This is checked exceptions all over again... Frankly, I
219.
by julik 4y ago
I know people will throw stones, but dynamic-oop-folks likely remember https://en.wikipedia.org/wiki/Croquet_OS
220.
by julik 4y ago
As long as it works the first time and everyone on the team is fine installing a local Redis - there is very little problem. If the code doesn't make assumptions about read-after-write consistency for jobs. There will be "problems
221.
by julik 4y ago
Thank you for the nuanced assessment, I would tend to disagree still.
222.
by julik 4y ago
Yes, mostly. There are a few things to take into account though: - No multiple queues - No priorities - Practically no scheduling (the delay is very limited) - Creating and tearing down a queue takes a lot of time and the number of queues i
223.
by julik 4y ago
I have used both SQS and PG-based queues and for the smaller workloads/smaller systems (read: "not very very large systems") I now prefer the latter. There is also a non-trivial amount of stuff that we turned out to need for
224.
by julik 4y ago
This is all fine and dandy but the article has a great point here. Redis is absolutely amazing, but if you bring it in you have to care about more stuff . Mo' stuff, mo' problems as they say. You now need to synchronize writes be
225.
by julik 4y ago
This.
226.
by julik 4y ago
A great article. I could probably give it some more depth with a bit of industry anecdote. VFX pipelines have dealt with actual film grain for a very long time (for about as long as there has been telecine/scanning) - and dealing with
227.
by julik 4y ago
That part is also known as "we had a very large post-production budget to consume so we decided to create a hell-ton of work out of nowhere". I've worked on a few digital-to-film-to-digital jobs back in the day and all of the
228.
by julik 4y ago
If the new hires do not reject the stack (or do the "this would have been so much better if it were written in Y") - in general, yes.
229.
by julik 4y ago
Besides the topic, this is an excellent example what corporate communication should be. We often blame companies for corporate-speak filled with platitudes and BS. This post gives a prime example how to do it right by externalising constrai
230.
by julik 4y ago
I can easily answer that - we have to look no further than the early 200s as well as the experience of our (GenX) parents. Where I used to work a lot of the things were settled by internal telephone calls within the office. On a normal work
231.
by julik 4y ago
They are asking for people who are ready to be exploited, usually without sharing either authority or rewards (for good outcomes) and without properly communicating risks (for bad outcomes). Avoid.
232.
by julik 4y ago
> then why apply for the job? Opportunism perhaps? "...once they fire all these annoying legacy senior people we can redo everything..." As well as going down in the level of the joint (going from an A-league startup to a B-lea
233.
by julik 4y ago
> Also, you don't promote people for non-valuable rewriting of stuff. You do once it is organizationally perceived as "modernization". Speaking from experience as I been on both ends of this (getting promoted for rewrites
234.
by julik 4y ago
Bad devs do not have reports they would have authority over. Bad EMs do.
235.
by julik 4y ago
And no extra agency and no extra authority. I've been in that spot, had the best 4 months of my life (lack of authority was painful). Then 2 clueless managers were hired above me.
236.
by julik 4y ago
This.
237.
by julik 4y ago
What I am getting at is if you don't hire devs _specifically_ who are happy working in your stack you are setting your team up for trouble. What was "I am more familiar with X" during an interview might as well turn into &quo
238.
by julik 4y ago
How about "you have some knowledge of stack X and you are committed to learn that particular stack and finding joy in using it"?
239.
by julik 4y ago
>You might be looking for a <..> specialist but you don’t want to attract people who are only interested in particular languages. Because that person’s narrow focus will hinder their growth. Exactly what I have been witness to was
240.
by julik 4y ago
Silent Hill was pretty decent IMO

More ›