[HN Gopher] Ask HN: Trouble learning things I view as solutions ...
___________________________________________________________________
Ask HN: Trouble learning things I view as solutions looking for a
problem
Even when these things have proven themselves to be very useful in
widespread use. This is something that is playing a major part in
impeding my progress, blocking my motivation to learning some tech
skills that are more in demand. Especially since I currently have
no job, so there is no real-world frame of reference to understand
why they could be important. Why they could save my butt one day or
make my life easier. At some point, long ago (2012-ish) I was no
longer required to do deployment for web, but unfortunately I never
caught up because I was never made responsible for production ever
again. So I am just familiar with old ways of deployment and missed
out on a lot of changes that led to where full-stack web dev is
today. This mostly goes for a lot of skills in CI/CD and cloud
that are in demand these days. Some of it comes up more in full-
stack job interviews, in terms of, do you have experience with XYZ
or how would you use XYZ in some situation. I have no good answer
for them because I haven't really learned how to use them. And I
haven't learned how to use them because I can't come up with
problem scenarios where they are a possible solution. For instance,
why do I need Jenkins and Chef when I can already test, SSH and add
scripts and cron jobs no problem. Why would I need the cloud when
my past jobs and clients got by well with a cheap shared host. For
uploading files I just needed to know at least two of these three-
Git, rsync, and SFTP. It's not that I actually believe most of
these things are "useless". But rather that my mind can't draw a
good problem scenario for them. So from my POV they look like
solutions looking for a problem. Maybe my experience just has no
good frame of reference for those things. Discovering a context, a
frame of reference to understand these tools and apply them-
especially without a job -that's what I want to figure out.
Author : jumbojax
Score : 43 points
Date : 2024-07-11 20:07 UTC (2 hours ago)
| sebg wrote:
| one possible way it to realize that it's all re-inventions of the
| same thing all the way down.
|
| Slack is just IRC with pretty icons.
|
| Reddit is usenet.
|
| Twitter is just AOL AIM away messages.
|
| Etc.
|
| One way that might work is to turn it into a game.
|
| Taking an example from your post, you say: "Why do I need Jenkins
| and Chef when I can SSH and add scripts and cron jobs."
|
| So work backward and write/post about it.
|
| Starting with SSH, cron, and scripts, here's how you can recreate
| Jenkins and Chef.
|
| Along the way you'll help other folks who also missed the boat
| figure out what the new technologies also do as well as give you
| some fodder for interviews where you can say, I reimplemented
| from scratch Jenkins using basic technologies and that's how I
| would use XYZ in this situation.
|
| Or, maybe you could try to focus on jobs where the company is
| scaling and actually needs to look at whether Chef, Jenkins is
| the best idea or whether it can be replaced by more optimized
| technologies that are used to using and have been "battle-tested"
| to an n-th degree.
|
| Maybe that could help?
| HPsquared wrote:
| The famous HN comment on Dropbox.
| https://news.ycombinator.com/item?id=9224 E.g. "For a Linux
| user, you can already build such a system yourself quite
| trivially by getting an FTP account, mounting it locally with
| curlftpfs, and then using SVN or CVS on the mounted
| filesystem."
| smaudet wrote:
| I _still_ don 't use dropbox (used it briefly a long time
| ago), replace ftp with sftp and cvs with git and it might
| still be true-ish?
|
| Another good thing about re-implementing, often these
| solutions are like 700 pound gorillas, built fast and trying
| to move trains not place flowerpots.
|
| Usually the 700 pound gorilla can be gutted, and the danger
| of not gutting it is that everyone starts to think that
| having 700 pound gorillas in your backyard is a "normal" part
| of "modern" living (dystopia living, actually).
|
| Which is how we arrive here: https://spectrum.ieee.org/cloud-
| computings-coming-energy-cri...
|
| Where arguably the tech industry is fast becoming one of the
| most wasteful, hurtful things to this planet.
| themoonisachees wrote:
| Right but the value proposition of Dropbox wasn't the tech it
| was built on, it was the fact they gave you free cloud
| storage in exchange for an email address.
| 1oooqooq wrote:
| in fact it was _despite_ the tech.
|
| Most my musician and composer friends were forced to use it
| because it was the cheapest way to share a few hundred
| gigabytes of instrument samplers with remote contract
| workers.
|
| They would reserve a week to deal with botched dropbox
| client upload/downloads. A freaking week. I convinced a few
| to just pay postage on a external HDD and bite the bullet
| if they got damaged. They never looked back.
| nitwit005 wrote:
| I suspect this is fairly common.
|
| But I'm also not sure self study will help unless you're willing
| to lie on the resume. People often explicitly demand experience
| with the particular tool.
|
| Which is why we see so much "resume driven development". People
| know they need experience with tools, so they generate it.
| ricc wrote:
| Keyword is _scale_ , specifically massive scale. If your scope is
| just a couple of (web)servers, then, yeah, you can stick with
| your tried-and-tested tools and processes. But once you start
| managing 10s or 100s of servers, including a requirement to
| recover (i.e., redeploy) them ASAP after an outage, then your
| basic tools and processes might not be enough...
| theovermage wrote:
| I've been in cloud / IT space for about 15ish years now, and at
| some point in the last few years I became quite jaded with all
| the new shiny tech things. I had a lot of trouble buying into the
| K8s ecosystem when I could do magical wonderous things with SSH
| and Ansible, and most conversations with my colleagues at the
| time were unconvincing at best - they would say K8s can do blah
| blah, and I would point to our Ansible playbooks that were
| already doing the same thing. The problem for me was less about
| the differences in technology but more about finding the
| willingness to learn something just because I have to.
|
| I've since learned to recontextualize these things in terms of
| people. CI/CD isn't good because it's better than SSH, it's good
| because people who speak English can understand a simple devops
| pipeline but not my custom SSH wizardry. It's a way of inviting
| developers and even non-tech mgmt folks into my arcane world of
| development / production and allowing them to see what's going on
| under the hood. My incentive now isn't about what CI/CD tech is
| better or worse, rather does it allow my team / peers to
| understand what I'm trying to achieve and join in. And ultimately
| that's what I get paid to do - I don't get paid to do cool tech
| stuff, I get paid to make other people's work easier, or at least
| that's how I see devops / CI/CD. I know I can always find easier
| ways to do things, but will they necessarily understand them?
|
| Just my 2 cents. Hope this helps.
| periram wrote:
| Very well said. These tools help businesses move forward
| without having to involve a programmer for every little change.
| Also there are quite a few analytically strong and talented
| folks out there, who do not know programming. Given the right
| set of tools, they can make quite an impact.
| ethbr1 wrote:
| You realize how much UX is important in CICD at the same time
| you realize everything outside of product/IT (and half inside
| IT) isn't version controlled, change managed, and/or
| automatically deployed.
|
| More user friendly dev tools are the way to get people to do
| these things.
| frank_nitti wrote:
| Definitely true. I've also seen even the most technical
| people benefit greatly from the artifacts produced by CI
| tools.
|
| When each commit (or each RC etc) has automated regression
| testing for output quality, performance, or XYZ metric
| critical for your business, the artifacts/reports from those
| code changes can be stored and audited when unexpected things
| happen during a release crunch.
|
| We've had teams that shrugged off integrating with our CI
| tools, then a "final" manual quality check on their release
| builds' output showed significant regressions in
| completeness/accuracy. They scramble all their troops to run
| through the merged commits to find the culprit(s), and
| jeopardize delivery.
|
| A basic CI setup could have posted perf/recall/whatever stats
| to their PR thread for each merged change, or better yet
| block the merge at some threshold for regressed metrics.
|
| I definitely had the same view initially of CI, similar to
| unit test suites or verbose structured logging... things I
| viewed as complete overkill. What I learned was that these
| things DO still feel like overkill until the moment you
| really need the ability to reliably audit how each change
| affects an evolving large system
| hobs wrote:
| It's funny that you say that because no management and barely
| any devs actually understand k8s, they understand its a resume
| bullet point and it sounds like the thing so they go for it.
| simonw wrote:
| The best way to learn any technology is to use it in a project.
|
| If you're between jobs you have more time to spin up weird
| experimental side-projects than most people.
|
| It's a bit harder to spin up sideprojects for stuff like
| Kubernetes because it's pretty expensive to run, but there are
| plenty of related technologies - like Google Cloud Run or GitHub
| Actions - that are excellent fodder for small experimental
| projects to kick the wheels on them.
|
| A great thing about side projects is that they're a risk-free
| environment for experimenting with new technology.
| mvdtnz wrote:
| You should work on developing a growth mindset. It sounds like
| you have a typical fixed mindset where you believe that the
| things you learned and developed early in your career are
| perfectly fine and there's little benefit to extending yourself
| further. This mindset will not serve you well professionally and
| I strongly suggest you work on that as a priority.
|
| Specifically to understand the benefits of CI/CD I recommend
| reading Jez Humble's book on the topic[0]. He's an excellent
| writer on the topic. You can also google his name and watch some
| excellent conference talks from him.
|
| The best way to understand CI/CD is through experiencing an
| organisation that is building and deploying at scale. But you're
| between a rock and a hard place if you can't find employment
| without that experience. Jez Humble's books and talks will help
| you understand the benefits and capabilities of these systems.
|
| [0] https://www.amazon.com.au/dp/0321601912
| pixl97 wrote:
| After working with F100 customers, the number of applications
| they work with across the organization is simply mindboggling.
| When you have tens of thousands of applications (not branches)
| managing this stuff gets out of really quick. Things like
| license management and tracking what applications are using is
| no longer just a task that can be manually done.
| x0x0 wrote:
| > _It 's not that I actually believe most of these things are
| "useless". But rather that my mind can't draw a good problem
| scenario for them. So from my POV they look like solutions
| looking for a problem. Maybe my experience just has no good frame
| of reference for those things._
|
| For lots of things your frame of reference should probably be sth
| like replacing very expensive and very limited engineering time
| with inexpensive tooling. That could be inferior. But I'm far
| more eng time limited than I am cash limited. Or, particularly
| for deploys, (1) blue-green deploys are great; and (2) it's
| easier to hire eng that don't understand how to use rsync or
| capistrano than it is to hire those that do. Just like it's
| easier to use github actions to make it very hard to deploy a
| branch w/ failing tests than it is to just rely on everyone
| running tests. (Which, in a perfect world, you could do... but
| here we are.)
| periram wrote:
| Scale, Complexity, Job Specialization, Organizational or Business
| needs blah blah.
|
| Let me explain.
|
| Imagine you have a team that grows from say 4 to 40 over time.
| All the initial programmers, business managers etc. have left.
| One fine day, you get a call from the client saying "The feed has
| not arrived today, fix it in the next 2 hours or we are going
| elsewhere (or can you please please please fix it ASAP) ..."
|
| What do you do? How do you prevent this from happening in the
| first place? What procedures / software do you need to have in
| place to even know what went wrong etc.
|
| Now let me give examples that these tools help you handle.
|
| 1. You need to view all the jobs that run on a daily basis across
| 400 of your servers. 2. You want to make sure that no changes to
| anything in production can happen without at least 1 more
| programmer and 1 more business person signing off on it. 3. A job
| / script fails partially, how do you assess the impact and move
| forward (you are not even aware of the existence of this script).
| 4. You have a backup script / job that needs to run on demand.
| You want to let your support folks run it or even the business
| folks, without any programmer intervention (you don't want to get
| a call every time someone in Japan wants to run this report).
|
| Coming to CI/CD systems, some of their goals are
|
| A. Codify the knowledge into scripts / configs and do not rely in
| tribal knowledge. B. Ensure that your code is always in a
| "buildable" state with the new changes (i.e. don't even let bad
| code in) C. When a build fails, notify the programmers who
| introduced the bug immediately D. Once a build is complete, send
| it to other systems for stress testing. ...
|
| Yeah large businesses can have very intricate and complex needs.
| They rely on generic and configurable software (proven and tested
| by other large organizations) to meet their operational needs.
| Also, given that you can hire people that are proficient in these
| tools, you can focus on the business needs rather then
| reinventing these tools.
| marcosdumay wrote:
| Yeah, that's the answer (it's a shame it's currently so low),
| but I don't think it's in terms the OP will be able to relate
| to. I'm sure he can achieve all of those examples already.
|
| So I'll try to refine it.
|
| The main reason an organization uses Jenkins or Chief instead
| of in-house code is because they can just post job positions
| requiring knowledge on Jenkins or Chief, instead of minutely
| describing the person's tasks and training newcomers on their
| internal tools.
|
| So, yeah, those tools do lots of desirable things. And slightly
| simplify a huge number of tasks. But the main reason one won't
| find a job without some experience with them is that they act a
| lot like competence standards on the job market.
|
| And yeah, for a job seeker it does look a lot like they are
| bullshit. (And they often are - Jenkins and Chief not so much,
| but others are a lot.) The OP's question is a lot like "why
| should I learn standard calculus notation if I can calculate
| everything just fine on my own notation?", and if you replace
| that with stuff like type theory you will find people actually
| asking that question. The answer is always the same, it's
| because you need it to communicate with other people.
| pixl97 wrote:
| >it's because you need it to communicate with other people.
|
| Yep. Chances are if they use Jenkins, they'll have some
| vendor plugins for tools they use. Jenkins will download
| xml/json from the one plugin and upload it to another. Now
| those systems are coupled via a format and a set of behaviors
| around it. For a huge portion of corporate users those
| plugins remove a huge chunk of work they'd have to do
| internally, and instead of writing something from scratch,
| they can extend what is already there.
| hawski wrote:
| My problem with Jenkins is that it very often leads to a pile
| of Groovy, that no one really understands and then some things
| can be only done through Jenkins instead of a developer's
| machine for example. That's also one of the reasons behind all
| those YAML-CI/CD configs that are trendy today, which (besides
| using YAML) I fully agree with. Also I hate that Jenkins pushes
| secrets through environmental flags.
|
| I understand that for most companies they post a job offer with
| Jenkins as one of keyword requirements and they are mostly
| done. That is probably much more important than any actual
| utility of the tool beyond tens or hundreds of thousands of
| lines of Groovy that someone has to maintain.
| mamcx wrote:
| > And I haven't learned how to use them because I can't come up
| with problem scenarios where they are a possible solution
|
| Well, you have a problem:
|
| > I have no good answer for them because I haven't really learned
| how to use them
|
| So if getting a job where that skills is important, learn is your
| goal.
| mixmastamyk wrote:
| Look up these pieces for some of the why's of the last decade or
| two:
|
| "Cattle not pets"
|
| "Html,css,javascript for dinosaurs"
|
| "Hypermedia systems"
|
| Kleppmann's Data Intensive Apps, and a good Postgres book. Data
| is the big focus today.
| enasterosophes wrote:
| I used to have the same issue, before it became my job to
| understand CI/CD tools. Previously, I was a research student for
| whom Linux, Git and programming were just hobbies; then my
| interests got me a foot in the door doing something that I found
| more rewarding: working on HPC and openstack.
|
| Although I'd heard of CI/CD before, I only had vague ideas about
| what it really meant. Then I had to learn Jenkins, Gerrit and
| Puppet to do my new job.
|
| I still don't use these tools for my personal side projects,
| partly because setting them up and maintaining them requires its
| own overhead. This overhead is easy to justify when you've got a
| team who is all sharing the resources and you're managing
| infrastructure with fleets of dozens or hundreds of servers, but
| it's less easy to justify as a "one man band."
|
| Conclusions:
|
| * Don't worry about it if these tools don't do much for you right
| now. Not everything is for everyone.
|
| * It might end up making more sense if you get a job where you
| need to collaborate with other engineers and people are judging
| your business based on scalability and site reliability metrics.
|
| When you _do_ get a job that requires such tools, this is why the
| ones you mentioned are important:
|
| * Chef (or Puppet, etc) are necessary to ensure your dozens of
| hundreds of servers all remain in sync with a consistent and
| reproducible configuration. We speak of "cattle not pets" -- in
| part, that means you don't configure machines individually,
| instead you enrol them into your configuration management system.
| The configuration management is stored in Git, so Git becomes
| your source of truth for how your whole fleet is configured.
|
| * Jenkins: It's a featureful service for running a wide variety
| of automations without needing to rely on third-parties like
| GitHub runners. Eg when you are collaborating on code, Jenkins
| can provide automated reviews, like giving you a +1 if the
| linting checks pass. When you merge the code, Jenkins can run
| additional tasks like deployment.
| itronitron wrote:
| The frame of reference to understand these is that they are
| targeted towards people that are unfamiliar with the preceding
| technology. The 'new' technology is obfuscated and hyped up in
| order to differentiate it.
| doctorpangloss wrote:
| Do you think the people who authored Kubernetes are unfamiliar
| with Ansible?
| sarlalian wrote:
| Maybe... but that would only be because k8s comes out of
| Google Borg, not Ansible. Ansible wasn't even a thing when
| Google Borg was already in use at huge scale.
| apwheele wrote:
| When you get asked questions IMO I would just swap out your
| experience for equivalent, e.g. do you have Jenkins experience -
| no, but I have created my own automated CICD processes to build
| test and push. (Part of the reason to do CICD stuff is to have
| another computer do that stuff in an org with many people
| contributing, but it is the same principle as you built locally.)
|
| For cloud I would swap out discussing rsync and SFTP in much the
| same manner, although that is slightly more of a stretch, most
| people asking those questions either won't know better or will
| know idiosyncratic cloud stuff can be learned if you are at that
| level.
| golergka wrote:
| > For instance, why do I need Jenkins and Chef when I can already
| test, SSH and add scripts and cron jobs no problem.
|
| New members of your team will not be familiar with your scripts
| and cron jobs, but they might know Jenkins and Chef, learn about
| them from the docs and fix common issues with Stack Overflow.
| satisfice wrote:
| Just don't learn those things. Sounds like your mind simply won't
| latch onto knowledge unless it is associated with an authentic
| problem. My mind also works that way.
|
| People will tell you to suck it up. Don't. Find interesting
| problems and then solve them naturally. You will learn lots and
| it will feel great. I wrote about this in my book Secrets of a
| Buccaneer-Scholar.
|
| I have used this method for my entire career since I became a
| professional coder at 16 after dropping out of high school. It
| may be important to note that I use coding in my work (software
| testing consultant, trainer, expert witness) but I am independent
| and don't do production coding for commercial products. I don't
| have the patience for all that. I burned out as a production
| coder when I was 19, and have been in testing ever since.
|
| In other words-- I get to say screw Jenkins-- I write my own
| frameworks and that's fine.
| altdataseller wrote:
| This x100 for me. I absolutely refuse to learn anything new but
| will go beyond to learn something if its absolutely necessary
| to solve a painful/interesting problem
| nonameiguess wrote:
| I think some comments are missing the points a little bit. It's
| not just about scale and I think not at all about not needing new
| addons to the project not wanting to decipher your bash wizardry.
| Deciphering Jenkins pipeline scripts or Ruby playbooks for Chef
| is no easier. In fact, fully figuring out what a Chef recipe will
| do without running it can be quite inscrutable, way more than
| figuring out a shell script.
|
| But Jenkins and Chef give you servers. The pipelines or recipes
| are in a central location with access control that can tie into
| the same sso or ldap controlling access to everything else in
| your IT infrastructure. They can run automatically without having
| to install separate cron jobs on every server you own. Your
| deployment scripts are probably running from your laptop, which
| is accessible only to you, not always connected to a network,
| probably not accessible remotely to anyone, may or may not have
| any of its own backups, might be unmanaged and impossible for a
| third party to know you're running it securely and it doesn't
| have malware.
|
| Organizations are trying to avoid having Dennis Nedry control all
| of the core infrastructure they rely on.
|
| Sure, as an individual consumer, I might have questioned the
| utility of something like dropbox, and as it stands, I have never
| personally used it. But I don't question the utility of
| distributed filesystems existing when you could just have cron
| run periodic rsyncs between the root filesystems of some
| arbitrary number of servers. Yeah, ultimately Chef and Jenkins
| are just doing what your shell scripts are doing. But Chef and
| Jenkins are real software. They're well-tested, have a formal
| development and release process that involves peer review,
| they're used by thousands of other customers, they come with
| support contracts and SLAs. Your shell scripts don't have any of
| that.
| LouisSayers wrote:
| It's your perspective.
|
| The real question is, given all the materials on the internet
| that can literally tell you why these tools are useful (I mean,
| surely if you just read the docs you'd find out?!), why have you
| not done the work?
|
| It feels like you're in your comfort zone and rationalising why
| you shouldn't do the work. I mean, is finding a job and being
| employed not motivation enough?
|
| Perhaps look inside yourself and be honest first. It sounds like
| instead of admitting that you need to do some work and learn some
| things you'd rather blame outside circumstances for your lack of
| personal progress.
|
| I don't mean to sound harsh - sometimes we just need a reality
| check!
|
| Take responsibility, get out there and DO THE WORK. A new world
| is waiting for you just over the hill.
| paulsutter wrote:
| That's great it will serve you well.
|
| Once you choose a problem to solve, then you'll have the
| motivation to learn the tools needed to solve it. So find that
| problem and solve it, and then maybe you won't need to find a
| job.
___________________________________________________________________
(page generated 2024-07-11 23:00 UTC)