HN user

asragab

144 karma

non-sequitur, psuedo-code bio, [Insert [Insert Comment Here] joke], newb, n00b, blah blah computers are fun and useful, quote from Richard Stallman, Larry Wall or Edsger Dijkstra

Posts4
Comments42
View on HN

You seem inexperienced, lots of orgs do not allow their devs to arbitrarily ssh into their webservers without requesting elevation, which is fundamentally the difference between autonomous agent development `dangerously-skipping-permissions` and it asking every time to use commands? Which is the point of a sandbox?

So a couple of things:

If the first thing you failed to accomplish after 10 years was a medium complexity task, consider yourself lucky in some sense. Also, who determined the complexity level of this task, did you decide it was medium complexity, and if so is that corroborated by the team?

Moreover, most "bad" programmers don't necessarily think they are writing bad code, did you come to this conclusion yourself? If you did, it seems like maybe some other factors came into play, maybe you didn't have enough time, maybe the requirements were unclear. In either case, 1 failed task seems like a lot to evaluate 10 years of a career on; having recognized this behavior in myself, you might be catastrophizing this failure in a way that's not productive for you.

If you received this criticism from somewhere else, that's okay too, being "over 30" isn't some death sentence, there's plenty of time to reinvent yourself, start a new career or rebuild your skills from the ground up - if that's what you want to do.

Maybe part of this is just, you aren't sure you want to be a programmer and you are using this "failure" as a kind of escape hatch, which you know, is also fine. Or, maybe you aren't sure you want to devote the effort you might think it would take to actually improve as a developer

I would say, check in with yourself, and figure out what you want to do or at least what you don't want to do. I wouldn't change careers simply because you think you aren't good at this one. Being a PM, has a whole other set of challenges (but if you are actually curious, the idea that you have to be able to "code it the right way" should not be a blocker).

If you do decide you want to become a better programmer, realize it's not going to happen overnight, but conversely it's not going to take as long as you think. But you do have to start somewhere. Rather than ask on HN, I would go find someone whose technical opinions you trust (you mentioned talking with people in the industry - hey developer evangelist is also a role out there for you, heh), and ask them to review some code you've written and have them articulate those weak points, and start from there.

If you decide to start, just remember to start small. It doesn't have to be late night grinding sessions, 15-30 minutes a day reviewing a topic, solving a code challenge, reading a chapter of a book - can really add up after a few months.

    “When you discuss languages it almost becomes like a 
    religious argument. But really a language is just a tool. 
    It’s like arguing, well, which one is better: a hammer or a 
    screwdriver? You tell me what you want to do with it and 
    I’ll tell you which one is better.”
But isn't this comment from a time, like 1984, when programming languages were quite domain specific. Can we not have coherent discussions about General Purpose languages, where we can actually say some languages are better than others, and while specific use cases should be taken into account; that it isn't quite like arguing which is better a screwdriver or a hammer?
  At this point a pipeline built on top of Stitch / Fivetran / 
  dbt is far more reliable than one built on top of custom- 
  built Airflow tasks.
I'd be curious if anyone who has used or integrated these products into their infrastructure could verify or comment on whether they are as effective as the author seems to suggest.
  If you hire a data engineer who just wants to muck around in 
  the backend and hates working with less-technical folks, 
  you’re going to have a bad time.
I'm not sure this was the intent, but I found this somewhat dismissive. I think communication skills are indeed important and being able to effectively explain technical considerations to less-technical parties (or parties whose technical expertise is not aligned with Data Engineering), but I have encountered in my own experience an active disregard for those considerations by data scientists as orthogonal to their needs at best or at worst, details for which they cannot be bothered. This is underscored by the notion that we, as Data Engineers, "muck around in the backend." We do, and we have to, and it helps to like it.

There are a few other areas of input and contribution that a good data engineering team can provide, that I don't think get enough attention in the post:

  1) Machine Learning Productionization
  2) Being a source of data expertise (consulting) with other 
     developers (working on services or the main product) in 
     the organziation
Regarding 1, while the author seems convinced that the ELT/ETL tooling and ingestion pipeline building can be taken off-the-shelf, I don't if it is as likely that there is the same kind of mature tooling for machine learning model deployment/integration. Though, I believe that is changing, slowly.

Does any know of a community of practitioners in a field or discipline who are by and large usually impressed by output of the members of that field on a regular basis.

Not rhetorical, asking for myself. I guess, I want to know how much more toxic are we as a community (to the degree you can talk about all folks who read or might read HN as a single monolithic community).

I mean, I know a few artists, they are absolutely savage when it comes to the work of others. Is this a dev problem or human one?

Introducing Hooks 8 years ago

What's actually funny here, is that maybe you aren't old enough. The "Super-cool" functional way has been around as long as types and functions, Lisp and ML have been around since the what...50's and 70's respectively. Immutable state and referential transparency are boring. Get off MY LAWN kid!

100% agree. Cyber true-crime, maybe? The toxicity of that place, of her, of Sunny! That guy seems like a real piece of work. I was struck by how amazingly well connected she was, collecting former and current high ranking government officials and industry titans. For me the highlight was the surreal depiction of that birthday party with Kissinger.

Yeah, maybe iterative as a concept is too facile a concept to contain what is meant here. Maybe "fractal", or recursive is better. Maybe though that's the point, it is hard after "multiple rings" to make code simple anymore, so better start off trying to optimize for simple first. Correctness requires exposure to cases you didn't know you didn't know (unknown unknowns).

This is one of the reasons why I am suspicious about the long-term saliency of so-called "smart contracts" on the blockchain. The immutability of code, while super amazing for digital assets, seems like a horror-show of a liability for dApps.

I think to those that are asserting that correctness comes first are somewhat missing the point. One, a simple solution is still a solution, that is if your code doesn't solve the problem, you can't stop. I think the author is suggesting that truly _correct_ code (code that produces the correct output under all circumstances) is only attainable iteratively, and if your code is not simple (and let's also remember here: that simple ain't easy!) than reaching correctness or performance will, in the main, be quite difficult. Not only will it be increasingly more difficult to reach a state of correctness again after a bug is found, and it will be found, but even measuring performance will become increasingly challenging. At least that's the lesson I take.

This article is ostensibly about how the current implementation of namedtuples has had serious consequences for the startup time of Python, because namedtuples are used in the compilation of classes (roughly). However, somehow this buries the lede...the most "interesting" discussion is kicked off by the first comment:

  Issues around the performance of Python and programs 
  written in it have far wider consequences than startup 
  time. During all the time any Python program is running, 
  its host machine is consuming power that typically depends
  on pumping CO2 into the atmosphere. If most of that power is 
  wasted, the effects go far beyond extra money to buy 
  it, or to operate extra servers, or users who wait a 
  little longer. The carbon footprint of a Python program 
  that runs throughout a data center, or many data centers, 
  adds up.
There was an article earlier on HN about the energy consumption pattern of Bitcoin/Ethereum and presumably any blockchain that implements a proof-of-work protocol/scheme, and between that article and this comment - I've started to notice a growing unease (I am probably waaay behind on the uptake) about the "world-eating" capacity of software.

I wonder how quantifiable implementation decisions like the ones exhibited by namedtuples in Python, which one might argue is an unfortunate/accidental side-effect vis-a-vis energy consumption, versus ones like proof-of-work, which I would argue are explicitly designed to be expensive.

And if anything should come of that quantification, namely, does optimizing code really become a moral imperative, and if so are there some usability and refactorability metrics that are often held in high regard that we ought to consider abandoning in the name of "energy efficient" software.

Obviously, this isn't a simple tradeoff, software that is difficult to write because it is highly optimized is difficult to maintain, and it might be the case that performance derived energy savings are outweighed by the energy cost of maintenance (literally, the energy cost of debugging and testing).

I am not necessarily surprised by the results.

It is worth noting that the second most popular "software tool" tucked in between oh-my-zsh and homebrew (both command-line tools/packages) is Tensorflow.

That has to say something about the current state of the industry, though admittedly, I am a little confused as to why it was classified as a "software tool" and not say, "a non-web library or framework."

Anagram Scoring 9 years ago

Actually, I think you did alright, especially given you found

11 counteridea reeducation

Which is not only anagrammatic morphologically but perhaps conceptually in some way in that counterideas are "mixed" into reeducation?

It would be interesting to find other anagrams that also share some relationship semantically.

Sorry, maybe I am being dense, but isn't that pretty much where it is? I mean, when articles talk about "cash reserves" don't they precisely mean immediately liquid assets, or does that include invested income as well?

One cynical takeaway from the story of Achilles and Thetis is that one can never do enough for one's children (or conversely) there's always an opportunity to blame someone else ;)

In this case-Apple, as the proud parents of the Mac, iPhone and iPad, a possible strategy, much like Thetis dipping her son again in the River Styx, is to find ways to take advantage of the same R&D across their product line.

I've always thought that a greater convergence between iOS and now macOS was in store. Maybe as a "pro" I wouldn't want that - but if it could make both better then that convergence in terms of financial and technical focus would be a win-win for Apple and its customers.

As the owner of a Late 2013 MacBook Pro (the best iteration IMHO) and the user of the latest TouchBar MacBook Pro (work laptop) I am bemused by some of the decisions Apple has made. Of course this article comes out on the heels (yeah, yeah, sorry) of the announcement that Apple now has 246 billion in the bank, so what the hell do any of us know.

Thank you for this. In your note on tools, I notice this line:

"I have chosen an obscure toolchain which lulled me with its elegance and iteration speed, while the actual runtime performance and capabilities suffered."

This always seems to be the faustian bargain, when going into the deep deep world of graphics programming and generative art. Not that these tradeoffs are unique, far from it, but it is exquisitely obvious and painful in this discipline. I commend the effort.

That's right. But it seemed for a while that the MacBook Pro had the feature set, hardware configurations and broad appeal that allowed both groups to be aligned on their hardware choices (i.e. a MacBook Pro).

It is perhaps too early to wave goodbye once and for all to that coalition, but it does seem like some of the design directions that Apple has taken have drifted away from that user base.

That said, this war on the professional and creative class of users began sometime ago - I think the introduction of Final Cut X was the first salvo, while the platform has significantly evolved from the first couple of problematic releases, I personally know some who considered the product a literal betrayal and abandoned ship to Premiere Pro or AVID.

I sense Microsoft is attempting to reassemble that coalition with their offerings, namely the Surface line (especially that gorgeous looking Surface Studio) and the introduction of Bash on Windows, which while still quite limited in its functionality, can be a seen as a step.

I really like my MBP 2013 (NVIDIA GPU) and I guess I am going to keep it a while longer.

What I envision a solution to be like, would be something like an configurable/codeable OpenRefine (was Google Refine) with streaming ingestion/extraction, with a validation engine/parsing engine (something more elegant than regex, but you can drop into that if necessary) and maybe a pluggable event processor (i.e. a Spark or Flink). I would love to work on such a problem, and solve it.

Amazon Go 10 years ago

I imagine this scenario has played out a thousand times when it comes to the socioeconomic effects of technology given the rapid pace of ostensible innovation. I think it actually is part of the problem, while not a specific critique of Amazon Go, to the degree that technology advances at a rate faster than we can make sense of their effects, we face the possibility of endangering the lives of millions of people. Theses and dissertations aren't the only means of understanding, but they are invaluable mechanisms for grounding the discursive space in a digestible format.