HN user

mb22

121 karma
Posts0
Comments40
View on HN
No posts found.
[GET] "/api/user/mb22/stories?hitsPerPage=30&page=0": 500 Failed to fetch user stories

I wonder if this is a misunderstanding on accountability. The demo days hold people accountable to others AND themselves.

There is a general movement to eschew accountability which is a huge mistake because this concept is critical in continuous improvement.

Slower != better

There are times to go fast and take on a little debt vs going slow and getting it right.

It's often hard to know the right time to apply the right strategy. I would like to believe that's what experience gives us.

what if the push to work 4 days instead of 5, and less hours in a day, and the wedge being driven between the founders and the proletariat is the result of a psi-ops from Russia and China to hobble the US from the inside. Convince the current generation that working hard and pursuing your craft is inherently a bad thing. I feel like this would work.

fabricated outrage. There is no reason why a "go for it" startup wouldn't be honest about the hours they want to get out of employees. You don't have to work here. It's not always a conspiracy.

at will, exempt employee. no overtime. There is generally no cap on the number of hours an employee can legally work in a day. Employer can ask for just about any hours, and you can quit if you don't like it.

Have a discussion. Present your case and listen to your manager's response. I can't speak for all managers, but I've never met a reasonable manager who wanted to drive our a good engineer even in this economy. Perhaps there was a misunderstanding along the way? Don't listen to the people who presume all managers are bad, have bad motive, want to screw you for stochastic reasons, or are 100% willing to execute their manager's bad plan. A lot of managers are ex engineers just like you that want to build great products, enjoy work and their engineering brains still exist and don't want to be a*h*les.

I find the UX horrible for different reasons, ones that I believe are pretty easy for microsoft to address if they just watched someone like me use the product. I have not experienced the brittleness, maybe what I am doing is more trivial.

I am an engineer with 20+ years of hands on keyboard, I've got projects that are now part of Apache, 1000's of stars on github. I've been CTO at a number of startups that have got significant funding. My point is to establish some credibility. I probably still suck.

Having said that, I have been working with Microsoft PowerAutomate for the past 1.5 years and while it has saved a lot of time and been overall a good experience, there are times when the no code/low code gets in the way and I wish I could just "drop into code" to get something done. Examples are things like data validation. This technology is not going to replace coding, the paradigm shift is really happening for people in the marketing and sales operations parts of the business. For these folks, this tech is life changing. In a lot of ways, this tech felt like when you try a new framework in your language of choice; at first it's super easy and you get hyped, and then you hit a requirement where the nocode/lowcode environment really gets in the way.

I hear you, and I'm not trying to be cagey here. I'm in the market for a very specific set of skills. The talent/experience/ability for this position varies wildly from "I know of Hive" to "I implemented the Hive CBO, check out my commits". What would I pay for the later? I'm not actually sure what the upper limit would be. I think for the average "engineer/programmer" job there is a pretty well known salary distribution and I know that we are on the upper end of, which is why I put "very good". For a specific specialist job like this putting a salary seems like a mistake, and not putting a salary seems like you are probably cheap. I might pay you north of $200k, but I if everyone that applies assumes they are going to make >$200k, it would be hard to take a less qualified person and adjust their expectations down, even if they would be a great hire for us. It's lose-lose I guess. Thanks for the feedback.

AtScale | Engineering | San Mateo | Salary: very good | ONSITE http://atscale.com

We built an analytics platform that works with all the modern big data platforms both onsite (hadoop) and in the cloud (BigQuery, Athena). Our stack is Scala (back end), Go, JS. We do difficult things, actual algo implementation and stuff verging on real computer science. We desparately need more people that know a lot about Hive, Spark, Presto, Impala, etc and are willing to make it very interesting for the right person. We have a great team with no churn because we trust them to make the right decisions and execute. Thank you and good luck in your search.

https://jobs.lever.co/atscale

this is a good discussion: http://www.northwestsourdough.com/experiments-with-autolyse-...

the answer, as usual with baking, is it depends. Salt definitely changes the chemistry. Salt mostly stabilizes the gluten structure and makes it stronger, but it can also inhibit development of new gluten bonds somewhat, particularly when the flour is initially hydrating.

You need to experiment, try a 2 hour autolyze before adding salt for a 24 hour cold rise.

OOoooO I like your style mister!

Let people post their results, correlated with their location and time to pull humidity from the local weather and give them a place to store results and we can crowd source our way to some serious pizza! :P

There is some good stuff in this recipe. It's a great starting point for learning.

I built a wood burning pizza oven and have been doing experiments for 5+ years, and what I've discovered is only certain things make a taste-able difference.

1. Oven. 900 degrees baby. Pizza cooks fast, and tastes delicious. You can get the "leoparding" on the edges. 100% worth it if you have time and space.

2. Yeast. Get the Ischia: https://www.amazon.com/Italian-Ischia-Camaldoli-Sourdough-Cu... it's a very light sourdough that imparts a delicious almost floral taste. I put a little bit of IDY in the mix to help sometimes, but this yeast is delicious.

3. Autolyse. Let everything but the salt sit for 30-45 minutes to generate gluten.

Here's my dough spreadsheet that auto calculates ratios and hydration %: https://docs.google.com/spreadsheets/d/1b46NnndcrK9ImRXx5BW8...

I'm happy to answer more questions if people are interested.

"feature requests that are fishing expeditions on the customer's part". This is a red flag. If your product market fit is strong, and you understand your value proposition, your prospects requests should fall somewhere on the roadmap. If they are too far out in left field, you may have other problems. The more your product solves a real problem, the more willing enterprises are to do things your way (take a patch every week, forgo some network architecture standards, etc). When selling, look for the signs that they are willing to play ball as an indication of commitment.

I've worked with Walmart a few times now, and they want to invest in innovative start ups, however they are also risk adverse and they want to mitigate that. Perhaps they look at your books to see if you are going to be around next week/month/year and the side effect is insight into pricing. They definitely push you to deliver, however it's usually pretty pragmatic stuff.

There is also a similar story for Siebel (Northwestern Mutual I think?). In enterprise software, buying from small companies is not the norm, so if some large organizations invest in your product, it can trigger the larger market to believe in you. I believe the trick is to make sure the "big" accounts you take on aren't ones that are going to take you too far off your normally planned roadmap. If you find yourself building one-off features, one for each customer, you are in for a world of hurt. If your big customers drive you to build your roadmap faster or more aggressively, that isn't always a bad thing.

AtScale | San Mateo, CA | Scala Platform Engineer | Full Time, On Site | http://atscale.com

We build analytics software for big data platforms. Originally Hadoop, branching out to the new serverless platforms such as Big Query, Athena, etc.

Our Scala team is small and very highly skilled. Engineers are treated like adults. We do very sophisticated things that are often challenging and never boring. We have never used a recruiter to hire engineers. We are winning in our market. We are very good at Fantastic Gymnastics.

If interested, shoot an email to me matt@atscale.com.

Atscale | San Mateo | ONSITE

Love Devops and hate the pager? Regularly scheduled after hours support is not required as there is no on-call rotation!

Our interview process is straight forward - 30-45 minute coderpad exercise - 2 hour in person to meet team, assess cultural fit, a few more questions about what you love to do - decision made quickly, usually within 24-48 hours

Atscale is a small, successful company in the Big Data space.

The job: Infrastructure and systems don’t need to suck; we believe deep understanding of fundamentals and solid engineering cure most woes. We are looking for a startup-friendly, devops person to work with the latest Hadoop tech. This is a challenging position and a great opportunity to learn the latest technologies used in the data space.

We’re looking for someone who:

Has a foundation in a language like Python or Ruby but feels confident to jump into a new languages Has experience with configuration management systems such as Puppet, Ansible, CFEngine, or Chef Will automate everything Proficiency of Linux at a systems administration level Hands-on experience with Jenkins, Git, Docker Can work closely with developers to solve systems problems. Blur the line between ops and dev Can optimize like crazy; squeeze every bit of performance out of servers Can help build a great company Nice to haves:

Has experience with business intelligence concepts Has experience with Hadoop, and Hadoop-ish stuff like Spark. Can change hardware (disks, laptops, servers, etc.); support network and security A literal or metaphoric Beard of Unix Mastery

careers@atscale.com http://atscale.com/careers

50 days ago on the "Announcing Spark 1.6 (databricks.com)" thread I mentioned that we were doing a 3rd party SQL-on-Hadoop benchmark (https://news.ycombinator.com/item?id=10837758) and a bunch of folks sent me notes asking for a heads up when the results were in.

Well, we are done with our analysis and have a blog post offering up up the bulk of the results - http://blog.atscale.com/how-different-sql-on-hadoop-engines-...

The blog has the majority of the results, and additionally there is a registration link for the full 17 page whitepaper if you are really keen on SQL-on-Hadoop. www.atscale.com/benchmark

Trystan, the engineer that did the bulk of the benchmark work, would be happy to answer questions regarding the methodology, hardware, etc.

Due to how fast these engines are evolving, we plan on doing an update to this benchmark on a quarterly basis.

We've been testing 1.6 since before release, specifically SparkSQL and there are some big performance improvements in this release. We're putting together a 3rd party benchmark I'll post to HN when we are done.