144 karma · joined February 14, 2016
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.
At the time there were some motions towards a "better MapReduce," Scalding (ooh weee that had a learning curve) comes to mind, but I feel like Spark really lowered the bar for getting big data tooling and the ecosystem into mid level and pre-ipo orgs.
“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.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?
I know this isn't the point of the thread, but I couldn't help myself. I will ask for forgiveness (as I am sure we have all done in both technical and ethical matters)
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.
https://github.com/bhauman/lein-figwheel
has that out of the box. As for an actor model implementation, there is pulsar:
http://docs.paralleluniverse.co/pulsar/
Which has erlang-like actors, though some might suggest that core.async and its channel implementation provides everything you might need an actor for, YMMV.
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).
The last item on the Roadmap underneath the "Core" Section lists multimethods.
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."
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.
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.
"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.
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.