skohan

38 ms·

451.
by skohan 5y ago
Isn't M2 potentially the first 3nm process to be released?
452.
by skohan 5y ago
I avoid first-gen products almost as a rule, but M1 has delivered on promise amazingly.
453.
by skohan 5y ago
Agree, it's a fantastic product. Performance is great, form factor is great. I don't every really think about the computer at all, just what I'm doing with it, which is perfect. If anything, I think the perfect machine for
454.
by skohan 5y ago
I mean it's always a bit of a middle ground isn't it? I'm not suggesting that you should literally just sit down at a keyboard and blindly start typing - of course you want to have at least some concept of how you want to
455.
by skohan 5y ago
But there's also such a thing as over-planning. If every function you write, you are thinking about 100 different rules about "best practices" you can end up not writing anything at all. Sometimes it's better to accept
456.
by skohan 5y ago
I guess I have been lucky - I've always been able to negotiate for time to refactor if needed, or just find time for it in lulls between tasks. If you're in an environment where engineers don't have the freedom to improve th
457.
by skohan 5y ago
> Kindly let the grownups talk Well one of us is certainly being condescending ;) And did you really answer twice to the same comment? My goodness I must have really struck a nerve.
458.
by skohan 5y ago
Yeah I mean for sure it depends on the domain. But it's interesting you mentioned compilers - I'm in the process of writing one, and I very much used an incremental approach. The first pass I essentially wrote a parser and a compo
459.
by skohan 5y ago
I think you might have missed the part of my post about eventually arriving at a well factored codebase
460.
by skohan 5y ago
Not that it matters but I've worked on a mix of green-field projects and mature codebases in various domains with teams of various sizes over more than a decade of professional experience. I could assume you're throwing shade on &
461.
by skohan 5y ago
I partially agree that there is a cyclical aspect to code rewrites and cruft accumulation. I still think a lot of time the perception that code is poorly written gets applied to complexity which is not yet understood rather than objectivel
462.
by skohan 5y ago
> communicating those ideas to less experienced developers is where the problem comes in and all the prescriptive dogma arises. I think a lot of it is just lack of context. A lot of "best practice" advice is valuable in certa
463.
by skohan 5y ago
Yeah I think that there's a bias for programmers to think about artistry, poetry, and idealism in the form of code since that's what we're dealing with all day. But in reality it matters a lot less than we would like to thin
464.
by skohan 5y ago
I think there are always ways to minimize coupling. For example if most of the code you write is pure functions operating on values, then swapping out your ORM might be a bit laborious, but it's going to be largely just a matter of
465.
by skohan 5y ago
Idk maybe it's because I did freelancing for quite some time and was often hired to clean up somebody's mess, but I think it's not so bad to rewrite someone else's code. What I normally do is quarantine the old code b
466.
by skohan 5y ago
You can also spend weeks trying to solve a problem on paper which can be solved with hours of experimentation
467.
by skohan 5y ago
I want to work with people who I trust to rewrite my code. And of course I don't mean that you should check in code which is a mess. But from the time you start a feature to the time you open a PR, you can go through several iteration
468.
by skohan 5y ago
It's not throwing it out the window if it's an iteration toward a better solution. There's a reason nobody does waterfall anymore in software - up-front planning is less productive than rapid prototyping in most cases.
469.
by skohan 5y ago
If architects could freely reposition beams in a building, they might take advantage of that fast iteration rather than spending a lot of time calculating up-front.
470.
by skohan 5y ago
If you write loosely-coupled code, it shouldn't be that easy to break things unless you're careless.
471.
by skohan 5y ago
But how often would you actually have to rewrite an entire 10-20k LOC project at once? As you need to add functionality, you can opportunistically find ways to improve the codebase toward a better/more maintainable structure. I have se
472.
by skohan 5y ago
What was the design error?
473.
by skohan 5y ago
Well starting from scratch for a rewrite is generally a bad idea. I'm more a fan of incremental re-wrties. But I have code bases I have been working on for years with tens of thousands of lines where basically the entire thing gets r
474.
by skohan 5y ago
I'm just having trouble understanding what you're talking about. Like what would be a concrete example of how a poor up-front design decision would paint you into an unrecoverable corner?
475.
by skohan 5y ago
I would argue if “high level design decisions” are getting in the way of coding, this is a sign of over-design or premature abstraction. If you write sufficiently loosely-coupled code, it’s not hard to re-organize later.
476.
by skohan 5y ago
Rewriting is incredibly cheap! And you learn a lot from the failed attempts. Again to the house analogy, if you could just build 3 vestibules to see how they fit with just a little typing, that would be far and away preferable to committin
477.
by skohan 5y ago
Yeah this just hasn't been my experience. If you're working on a house you measure twice and cut once because the cost of reworking physical materials is a lot more expensive than the cost of doing a second measurement. If you co
478.
by skohan 5y ago
Yeah sure! One realization which helped me with this: how many people will be affected by how your code is written , vs what your code does ? Given that, where should you put most of your effort?
479.
by skohan 5y ago
Disagree. I feel like I have seen this play out a number of times in my career: - New engineer joins a team with a mature codebase - New engineer complains about code quality, convinces management on a total rewrite to improve code quality
480.
by skohan 5y ago
My biggest problem with code reviews is that they are so often without value. Code review should be a chance for teams to learn from each other, catch issues, and align on coding practices and strategies. In my experience, a lot of the ti

More ›