HN user

smashface

69 karma
Posts0
Comments26
View on HN
No posts found.

Skimmed article mostly.

Could things be better? Sure. But saying we're "wasting" all this time seems a little disingenuous. How much time do people spend maintaining tractor equipment to grow crops? Or really any tools of any trade?

The equipment and tools we use let us be more productive overall with certain tradeoffs.

We have a project that is basically an internal, stripped down version of CodePen and others like it. All code samples are stored in git.

The main challenge for something like our app is search. Git is good at creating files and managing versions/branches but not good at search files or their content. I'm not a git expert to fully backup that claim but that's been our experience. You can layer on your own search capabilities if you need it but then you might want to start asking if a full DB is better.

I work on internal UI libraries that we use in our products. We updated our designs maybe 4-ish years ago and we're already getting feedback from customers that our designs look dated.

Unless you paid cash, your bank or credit card company will remember the amount for you. I don't know if most restaurants receipts are going to itemize the bill. But even if most do you can just say you went to one that didn't.

A thought I had recently was to shift from having candidates write code to have them review code. I'm sure it's not an original thought, but it comes with a few advantages. 1. Reading someone else's code is usually harder than writing your own and in most projects you spend more time reading code. You're seeing how they'd handle the more common work. 2. You can still pick how deep you want to go in the interview. Like some of the algo problems where interviewers keep adding new requirements, you can discuss API design, performance trade-offs, other code qualities. 3. You get to see how respectfully they can discuss a future colleague's work and how well they can communicate their own ideas.

SAS | Web UI Developer | Cary, NC | Full Time

https://erp-sas.icims.com/jobs/20579/web-ui-developer/job

Looking for early mid-level developer for a web developer position. Our team builds an internal component library that gets used across a large number of web applications that we ship to customers. We're building our next generation of the library in React. This is rebuilding the whole thing from the ground up using some of the latest modern tools we can find: Storybook, Jest, TypeScript, functional/hooks-based components, etc. We have some tight accessibility requirements and so having a11y experience is big plus for this role.

SAS is regularly recognized as one of the best places to work for in US and around the world. On-site gym + pool, health services, day care, subsidized cafes. Full suite of standard benefits like dental, medical, retirement, etc.

Some of them look good but some of them are terribly designed. The rankings for testing graph shows storybook visually trending down when it actually increased in satisfaction.

I like the idea of this project. Its main goal is to highlight the bias towards English in programming languages and computer science and I think that's a great goal. I also think another great use would be to provide a stepping stone to those who are native Arabic speakers to get into programming. There will still be the English barrier to move on to other languages (and likely more professional or "serious" work) but if you can convince people that programming is interesting in the first place, this could encourage them to keep going further. As it stands now, if you don't speak English you would need to a certain amount of English AND programming languages. Languages like this means you just get to learn programming first while we figure out how to remove English as a barrier to entry.

Fair point. There is a better way to phrase things if there was no intent. And is evident in this thread, intent doesn't change impact. Having colleagues, that I respect, who work in similar roles I perhaps should have considered this better.

I think this may be a better way to phrase what I was thinking. It doesn't have to be directly related to revenue. The revenue relation just makes it easier to be counted as core to the business model. I think it's important to say business model too. IT is core to essentially every business now, but when IT is core to the how the company fundamentally positions itself in a market it really changes things.

Though in the context of this thread, I don't know a good question to ask in an interview to tease out that information when it's not already clear. If you simply ask "is IT/engineering considered to be vital to the business model or core to company success", everyone will answer yes regardless of how the IT/engineering is actually viewed.

I assume the author meant that since those teams will be speaking a lot to people as part of their daily work they add a lot of ambient noise to a workplace. That could matter to some people in open office plans or cube farms where you can't separate yourself from that noise.

I don't think the GP intended to call engineers at those kinds of companies lesser. I think the point that was made was that working at companies where the company makes more revenue by having better software is a better company to work for. If your role is a cost you're treated (explicitly or implicitly) as such. It's a lot easier to show your value to a company by being part of the revenue side of the equation. Reducing costs is great but there is a bias towards investing to generate revenue vs investing to reduce cost.

If by table-ish layouts you mean using the <table> element to render something like this then browsers might be OK at it but the <table> woefully inadequate to do anything more than the most basic table renderings. Virtual scrolling or frozen rows/columns is a lot of manual work to do on top of a <table>.

It seems logical that more people would apply to jobs that include a salary in the post. I'd be far more interested to know what % of employers are satisfied with their hire if they included the salary or not. Additionally I'd want to know how many people they found were outright unqualified if they included the expected salary. My suspicion is that lots of [un|under]qualified people see a great salary and apply just hoping to luckily land the position. That's not say well-qualified people shun seeing the salary in a job post (as is obvious from the comments here) but how much signal:noise do companies get.

This is a much better example of the point the author was trying to illustrate.

Though I'm not sure sure if the HTML / TeX comparison is the best to exemplify the concept. I feel that if a beginner were to make the conceptual mistake that HTML tags are not nested that they may also not grasp that {}'s are to be nested as well. Thus falling into the same trap as HTML.

I'll admit that {}'s look more obvious to form a nested structure but it may also be that my eyes are trained to see them exactly as such.