494 karma · joined April 20, 2010
Interests: Cybersecurity, Freelancing, Mentorship, Open Source, Music, Networking, Philosophy, Privacy, Programming, Remote Work, Research, Science, Social Impact, Space Tech, Startups, Technology, Writing
---
Yup, that's the most sensible option but the fitment really depends on the context.
> 2.
IMHO, more thought is definitely needed, in case you want to avoid expert beginners subscribing and cancelling it after a couple of months/quarters
> What's your background building these types of tools, if you don't mind me asking? Definitely down to discuss more!
Have been designing and building dev/rel/ops/maint/mon/ALM tools for the last 13 years, in large firms, SMEs and startups
Just a few points that I would request you to dig further.
1. Quick immutable envs aren't so much of a problem for B2C apps. Particularly for B2B apps, it's not just the "run-build--pull-image--deploy--start-svc--share-url" that's the real hard part. The real hard part for B2B apps is the test data - the sane dataset which needs to be replicated as well, per environment. Nobody wants to use a test/staging DB where changes are uncontrolled. Bottomline - Immutability isn't just at the app layer, has to cover the test data and stateful parts (datastores) too.
2. What's the real value of it? One possible way to figure out hassle-to-value ratio, is the ratio of number-of-commits to number-of-builds, and the ratio of number-of-builds to any number-signifying-quality. If more builds (=> more number of envs cropping up, and brought down, that is a high rate of env churn) do not mean increased quality, then anyone choosing such a solution is really just doing it for the sake of feeling self-important or sounding smart.
One really has to be keenly tuned for the real business value, while validating fitment of such tools for the org/business.
Happy to discuss more. I have been designing/building tools like this, as a day job for quite some time.
*govt
1. Enterprise readiness (in order of precedence: real business value [either brings money or saves good chunk of money], robustness, usability, integration capabilities, ease of on-onboarding, simpelr path to value-maximization. Good to haves: delightful user experience, great documentation)
2. Developer delight: The ecosystem (=> tools, platforms, training, autonomy, agency, motivation via empathetic management) offered to developers, in order to make them super effective, productive and efficient - to cater to the above listed. Note: "Developers" include Ops and Tech Support personnel too!
3. Customer delight: The above two leads to "customer delight" They see that the tool/solution clearly brings value, and that the support team is able to deliver the same as well - sustainably and happily.
This leads to a great win - for vendor and customer.
Building such an ecosystem is not a trivial or simple thing. Takes years, decades even.
In the end, that cutl gets formed - thanks to those ingredients that continuously keep "wow"ing the makers and the users. The "stuff" takes the limelight, but that's just proxy for the makers, their tools, skills and motivation.
This applies not just for software, but for many others! People value Toyota because Toyota's entire organization structure and inclination is on those lines - to 'drive' better value for consumers and their own people who offer'em.
Cheap human labour from impoverished parts of Asia and Africa is one very possible option. The supply chains are already there.
I personally know a few people from villages in South India, who had been trained in that kinda job - dressing up in heat-controlled suits, driving sand-buggies and operating large-scale-wipers and cleaners - to keep panels clean. A similar one is in India too. And some of those firms put in place a locally adapted solution - which involves a lot of wastage of resources of other kinds (water, manpower).
More info: https://spectrum.ieee.org/energy/renewables/the-pros-and-con...
Ex. PyMSSQL is now officially supported by MS. This implies, their costs of maintaining an ODBC driver for Python-MSSQL will be largely reduced thanks to the OSS model.
Same deal with Linux-Azure tooling (there have been many tools that came out), or be it .Net-Core.
They are looking at "extinguishing" Linux not by doing better than competition, but rather by absorbing the competition and getting them to work for MS in the long run. Great business move, not sure for the larger ecosystem.
But then, OSS will always be there. If not Linux, something else.
https://sourceforge.net/projects/linuxfxdevil/
https://b00merang.weebly.com/windows-10.html
Leveraging the FOSS work and cutting down on maintenance costs, and focus that only for LSW, to guarantee the functioning of that abstraction layer, and leave the harder parts (hardware support, security etc) onto public to pick up - at the cost of a few coupons, t-shirts, coffee-mugs etc thrown at them via "hackathons". (And even perpetuate the "passion for software" hence "public github contributions". May be give a slightly higher tier github subscription for free, they've bought that org anyway. And people are anyway suckers for Internet points)
It is 2020, every other HR who wants to squeeze out a little more time for themselves (may be to use it to browse insta/whatsapp/FB) would end up using some shit "AI/ML tool" sold by some snake oil vendor portraying it as suberb intelligent automation that aguments recruiters' intelligence for recruitment, at scale.
Every one first has to please the API/ML-model even before a human casts a look at the resume.
Tune resume to be read easily by a machine.
nginx - { static file serving, good proxy for python/ruby apps, req manipulation with advanced scripting capabilities via lua engine through open-resty [mirroring, WAF(naxsi), url rewriting etc] }
A combo of haproxy + nginx would always bring good delight for many practitioners.
Hiring Manager: I need a person with 10+ years of exp
Sourcer/recruiter: Ok, what skillz?
Hiring Manager: Cloud, Dev, Ops, SysAdmin - 10 years
Sourcer/recruiter: mhmm, what else?
Hiring Manager: Oh, also, someone with good k8s experience will be great!
Sourcer/recruiter: so, that's like, how many years?
Hiring Manager: one or two on top of the ones I said before
Sourcer/recruiter: Got it!
This "12+ years with k8s" "15 yrs with React" "10 years with Powershell 5" situation is because of such disconnect. Having worked in that industry sector has made me so aware of how broken hiring is, it is such a dark and gloomy present and future - aided by more tools that get put by people who do not really want to solve the problem but just make it someone else's.
Yes, absolutely. However, when orgs start using that against the individual to drive down pay or eke out more from the person, is when that show starts becoming to cliched and downright exploitative.
A civil engineer who is good at what he does and loves construction will not (easily) let anyone in his team have wrong proportions of concrete and sand, cause he understands the ramifications. But that passion in him towards the trade should in no way be constitued by his employer as a notion indicating that he could work for lesser pay cause "he seems to be loving that work anyway, so that actually is a perk!" (IT IS NOT!)
I have found good succes with the following approaches. Being in a small firm helped, but I haven't had too many difficulties following this in a large-ish firm too. (product unit in an Indian firm)
- don't hire in urgency. I believe in building a talent roadmap/planfor the team, capabilities over next 6 months, and thus hire someone who I see fit enough to grow into that role
- have a questionnaire sent before, which has open-ended topics ( views and perspectives on containers, infosec, cloud, imperative vs declarative, microservices vs monoliths, their fitment (and otherwise) to use-cases - etc)
- talk about a recent tech challenge the person was able to tackle and resolve, try getting to extreme levels of detail (to understand whether the solutiion was a true fix or just a patchy workaround), the tradeoffs made while going that route etc
- try to do a systems design session, jointly. the problem statement closer to the actual line of work
- try to use a seemingly open ended objective (cost optimization, reduction in MTTR. increase MTBF, increase scalability etc) relevant to our line of work or current set of problems and see if the candidate can find a good set of questions to find their way towards a workable solution, etc.
- for simpler stuff, hiring interns and then grooming them into productive, trained members of teams is often a useful way
- responsibility doesn't end at offer rollout. setting their teammates for success till they are in the system is the leader's responsibility
However, when am on the other side (am the one who is answering, pursuing a job elsewhere), I have come to hate the find-the-algoninja ritual so much that have stopped taking up any that forces such a deal. Am better off retaining my sanity.
All this BS "weekend-extra-open-source-labour-tax" must be borne by the members opting for tech streams. The innate, simple truth is that all that "weekend extra effort" is a way to see if the person can take up more work off hours without so much of a complaint and not demand overtime pay - in the name of "passion".
Passion is overrated. There are many who play the passion card, while trying to showcase their role-playing fantasies in a very skewed way. Hiring based on such appearances is at best just a gamble. There are many such "social profiles" which are either crafted for befooling the spectators, or inane content which just about passes the "100 for effort! value, best left unsaid!" types.
- more such biases creep in to the models, thanks to groupthink, multiple developers/groups and their biases
- such systems end up gating the applicants before a human view is cast on the resume
This is happening now, at scale. And only a very few in the industry seem to be really tuned about such dangerous bias perpetuation engines.
This is actually solved by this approach. Nobody needs to quit, a week's leave/vacation is good enough for the trial period. Or, am I missing anything?
It's too easy to fake "expertise" and "culture fit" over a 2/3/4/5 round interview each lasting an hour or so.
Most companies who deem this mode as not an option, simply aren't looking for great experts or engineers, but rather a cog in the grand system of wheels to keep the show running - or what HRs end up calling - a resource!
Solution: What can engineers do for this problem?
1. Propose this option (1 week PAID work trial) to HRs 2. Keep a backlog of technically engaging, but smaller work-items which could be taken up with least amount of background-knowledge , or something that has an easy-ramp-up-path for a newbie in the realm 3. Iterate and improve
This is just an extremely condensed internship of sorts. And many firms understand the value of intern-to-hire path.
Most cheapo shops which won't pay FAANG salaries but still want near-FAANG-quality-engineers end up using this as a bait.
Other ways are "your work has great purpose!" "You will advance humanity!" "You will bring great experiences to users" ... yeah yeah yeah, just an alias for "we are a glorified bodyshop. BigCos hire us for some piecemeal job. We get it done and get paid relatively well." But this isn't too appealing, is it!
Pray enlighten the rest of us as to how the current regime favouring one particular corporation isn't fascism?
Where is this definition of "urban naxal" defined? Just because one thought so? If speaking against the atrocities of authorities is being "urban naxalism", most of the current leaders also did so, during the emergency in India. Is there a Retired/Erstwhile "Urban Naxal" title too, for them?
Please keep HN civil. Your ultra-right thoughts can find good currency on Twitter/Reddit.
HN being invaded by ultra-right, on a thread that talks about caste-based discrimination.
Guess it is enough Internet for one day!
Participatory democracy doesn't mean that responsibility ends the moment one gets off the voting booth. In fact, the resposibility starts right there, by casting the vote, to ensure that the representative works for the benefit of people.
Us Indians just find the latter part, of dealing with that responsibility, a lot harder, and just convince ourselves otherwise.
And anyone else would get termed "activist" "leftist".
Left => left nothing. Left out off the mainstream (development, benefits, facilities), for being contrarian.
Not left as in left hand side.
It would most probably have a twisted answer as "you can post that solution of yours in your git repo and showcase it as a part of your portfolio"
Many shops out here are so adept at this stuff, it's no more funny!
https://www.medianama.com/2020/01/223-the-great-indian-firew...
A Great Indian Firewall is shaping up. Now that the sentiment is all "anti-China!", people would celebrate instead of protesting the great firewall.
"Masterstroke!"* - Indian public.
*Basically, anything the current leader does, his PR team and his party spokespersons end up terming "unprecedented" / "masterstroke" / "genius move". Everything seems headed towards hardcore Soviet scheme of things.
Exactly. Everything else is just a marketing gimmick. They don't even support interoperability between OOXML, thus crippling every other "enterprisey" user who might want to have usable content/data between their co-workers who might be using Windows
MS-Uservoice has ~500 comments on this topic since 2018, and no word from MS till now. [ https://office365.uservoice.com/forums/264636-general/sugges... ]
Guess they figured out WSL is an easy ticket to
- paint the picture that "MS <3 linux! Techbros, dont'cha see! Yeah!" - thus counter the "Hard for Ubuntu/Fedora/Linux users to use MS Apps!" argument by going "Know what, Ubuntu is within Windoze! No need to dual boot now! Wow! Such advancement!" and find a way to safeguard and maximize license/OS-aaS revenue
- no need to ever invest in interoperability for OOXML and such defined standards (this is a great lesson they have learnt from the LDAP-MSAD story)
- no need to bother much the "situation" of dual-boot - now there's a better way, by saying, "you could run Linux within, with full native suppirt, and no need to go out-of-band from your corporate security and compliance baselines! So much win, ya'see!"
Look beyond the gimmicks, and one could see it's just the same objective - just a different approach now.
Not just "Windows on every desktop" but rather, "all data-processings units in the world to directly be leading in one way or other to cause some kida revenue flow for MS"
Oh! Can you provide more pointers, please? A quick search doesn't seem to be showing anything worth useful on this item.
If we consider high composability, non-ambiguity, clarity, expressability (even a word?) as aspects of "human readability" - YAML doesn't go very far in the scale across many of these. A language, with slightly more appealing (yet non-limiting for programmablity) declarative constructs seem very helpful for needs like this.
It would be great to see any spider-web-graph of all these solutions across those aspects and thus help someone to take a wiser decision.