ritchiea

Thanks that is actually great advice. I added an addendum suggesting let agencies know he could use interview coaching but avoid details like where he's applied already or to how many companies.

Have you been looking for security based roles and pen testing type roles? It sounds like you enjoy that type of work moreso than you'd enjoy a typical software dev job where you're building web forms or APIs that return JSON etc. I would also second the suggestion that you speak to recruiting agencies but even through agencies first look for jobs in security that could take advantage of your natural curiosity in that area. You sound naturally in love with technology but not necessarily a builder. And that may not be a bad thing if you can just find the right opportunity. Also maybe reach out to Hacker News user tptacek [1]?

And if you do use agencies ask for advice/coaching through interviews from day 0.

1. https://news.ycombinator.com/user?id=tptacek

This is great advice. I would add: don't wait for them to coach you, tell them what your strengths are and how you've had trouble finding a job at big tech companies. Let them know you're open to smaller and lesser known tech companies and that you want to be coached to help you with the interviews. Because you're striking out at the interview stage and you know you can perform better.

EDIT: based on the first reply I got I want to revise this slightly. Don't go into too much detail about who rejected you or how many times. In fact keep the details short but make it clear you think interviewing is a weakness they should coach you with

The UK has aspirations to be American, see: leaving the EU, deregulation and attempts to dismantle the NHS.

Sadly the UK are not the only European country with these types of aspirations. My best guess is that there are tightening relationships between the tops of the political and business classes in many countries. And they are beginning to realize they can engage in unmonitored corruption while running disinformation campaigns to cover their tracks. And then running for re-election on populist rhetoric to maintain the appearance that they are the opposite of their actual policies.

This happening on both the left and the right. Though I would say on the right the problem is considerably worse (this may just be my personal political bias, take it for what you will). The few people that are paying attention to this kind of misbehavior are the extremely informed. Who of course are a minority. Society is stratified across the globe and the very poor and poorly educated are being taken advantage of.

Most politicians don't believe they are engaging in corruption. But there are a limited number of government contracts to go around, the contracts are increasingly valuable, and on the demand side there are a growing number of humans and companies. At some point you might have half a dozen or even dozens of "qualified" looking applications for a government contract. And the procurement people within any given government usually end up picking between the many possible qualified looking applicants by the fact that someone has a social tie to the inside.

The only possible solution I can think of is accepting some type of randomization in the assignment of government contracts. Because proximity to power is way too important right now. And the politicians don't feel like they are engaging in corruptions they believe they are giving their friends who have risen through the meritocracy a deserved opportunity. There is some truth to this but the problem is their friends aren't the only people who have earned similar opportunities.

Possibly but particuarly on a small team there is a cost to operational complexity even if you're comfortable. If the team could be developing features but is dealing with an infrastructure problem that could easily be dealt with via an abstraction layer then you still lose overall developer productivity.

And Heroku was never a great solution once you reached a reasonable level of scale because it became expensive and your Heroku infrastructure became subject to unexpected issues in resource sharing within shared instances. Shared instances are a problem across all cloud providers but pure-AWS-sans-Heroku is easier and has more options to switch to private instances.

I am a bit of a PG critic myself at times but he became rich from selling his own startup. He became richer by starting YC but he didn't need to start YC. Based on his essays he basically had enough money to be set for life from selling Viaweb and when he started YC he was looking for something to do next other than just retire.

Not even just luck, there are biases in who gets funding in the first place. PG himself says he's biased toward founders that remind him of Zuckerberg and other past founders. That group is very predominantly white and affluent with a small cut of Asian-american and affluent and a small cut of other.

It helps a lot to have an affluent background when you start a tech company because, like a lot of other risky endeavors, even though the potential rewards are enormous it's a lot less initial earnings than just joining a company as an employee. And you worry whether if your company doesn't take off and get its next round of funding in a few months if it'll be harder to get that first job. And you may be poorer than you were pre-startup.

Not to mention that poorer kids might not ever see starting a tech startup as an option. Both because of the biases in which founders get funding and because they may culturally never have the option floated to them.

Interesting note: Douglas Crockford's version of JSON's origin story is great. At Yahoo Crockford wanted to return data from an API as a Javascript object because it skipped a translation step and avoided messy XML. And his bosses originally objected because there was no JSON spec. So Crockford bought a website, quickly wrote up a JSON spec and published the spec to his new official looking JSON.org site. With an official spec in place and documented on the web, there was no longer cause for his bosses to object to APIs returning JSON :)

It’s dismissive to call it luddism. I am a big anti-GraphQL voice but in the specific cases where I tend to work: on small cross functional, often full stack dev teams. It’s a layer of formal promises about the API that I find extremely unnecessary & unproductive for small teams that I can see the appeal for at a huge corp like Facebook where frontend devs probably don’t write much or any backend code.

The problem usually isn’t the library itself and that’s true of GraohQL. It’s the cargo culting of GraphQL & other new tech that might be unnecessary or overengineering for your specific use case.

The great thing about GraphQL is that it's declarative and you have to write your own actual logic to define how the fetching of information works! It only does half the work SQL does! Everyone should switch to GraphQL ASAP!

Reed College

It doesn't take 2 weeks to set up an app in a language with a big community of developers, well maintained libraries and at least decent documentation. It probably takes a day or 2. Maybe a bit more if you are venturing into a new ecosystem like switching from Java backends to a node.js backend.

I loved learning Haskell in university. It's an interesting language. I came into intro CS class thinking I could already program & the class would just be about sharpening my axe. Then my intro CS class started with Haskell which threw my brain for a loop and made me think about programming completely differently. That was a great intellectual experience and good for my long term thinking.

Haskell also seems like an incredibly impractical choice for a production language that only a stubborn purist would make. Of course the last bit is purely opinion, your experience may vary.

One charge of mine lasts months, why on Earth would you need 2 mice? Worse case it runs out of battery and you take a 20min break to get enough charge to last you the rest of the day then make sure to charge overnight.

It's a practice that's so ingrained and so taken for granted that I suspect it will not change unless a big popular package gets hacked and the vulnerability effects a significant portion of apps written in a popular language like Javascript or Python.

And I'm not really arguing against vetting your dependencies or improving dependency management. I'm just saying in the real world, that if I made this particular imperfection in software development practices my hill to die on at work, there's a 99% chance it is not good for me or my career. So my options are, swim with the tide knowing we're doing things imperfectly, or fight an uphill battle for a more perfect world knowing that unless we avoid some major vulnerability every other Javascript developer falls victim to, there will be many eyes in my office staring over at me wondering if my extra caution is really worth the company's investment. If I keep my job at all.

I want to write great software, but to do that, I need to actually have a job writing software. And until I get a job at Google or Facebook or Amazon (none of those being places I've ever actually applied to) I am generally working in conditions without the resources to do the kind of dependency vetting we're talking about in this thread.

Ok so you're going to argue to an engineering manager or product manager that you need a day or days to do a full code audit of each external package you use? Or write your own library instead? That's, if anything, more unrealistic than just writing your own package manager.

Do you actually get to do this wherever you work? Honestly it would be great to have the luxury of that kind of patience and time to invest in my work. But it's universally unrealistic in my experience.

This is not at all a question of "what would be the ideal or perfect scenario." This is a question of what's pragmatic and politically accomplishable in most work environments.

Some developers are fearful of writing original code. Others realize it's not going to be appreciated by their colleagues to write their own package manager to solve a problem most of the industry disregards. Imagine arguing for getting the "write our own package manager to replace npm/yarn/pip" ticket into a sprint.

You can call it laziness but lots of developers correctly assume they'd be out of their jobs or at best out of favor at their company if they raised a fuss about dependency management rather than use (flawed) industry standard tools and get to work on features.

No one gets fired for using npm, you might get fired for insisting you build your own dependency management system because npm is insecure rather than working on your team's domain problem.

I hear game dev is the worst paid as well!

Great for her, amazing that she was working at the type of organization that actually wants to keep people around. This coming from someone who recently had my work praised for 6 months then was let go just before my probation period ended.

I wasn't a freelancer at the 2nd company, I signed a full time employment contract with the expectation I would be employed indefinitely as long as I fulfilled my duties.

Here non-EU foreigners aren't eligible to receive social benefits like unemployment income until after we've been here and paying into the social safety system for 2 years. So the 2nd company should have known they were letting me go without any government support coming. And it's not so much the money that's the issue, I have another freelance/consulting job lined up starting soon. It's just the frustration of investing myself in the work to only get in return broken promises and being replaced despite very positive feedback.

As for the first company, they paid the invoices, just were incredibly unprofessional about it. Including insulting me for "daring" to invoice them for full time work at the agreed up on rates. I got my money but they irreparably damaged the relationship.

I commented on this in another reply here but I think in the first case it was a founder that was just unprofessional and had difficulty getting along with other developers. And in the 2nd case it was a company w/o any product or dev team and I thought the opportunity to build my own team and choose who I work with would be fun. I just never imagined if I was making progress, shipping features and hiring good people they would use that progress to hire someone with a fancier resume than mine above me rather than appreciate my work & continue in the direction we were going. Maybe I was naive.

Thanks for the advice.

Thanks for the advice. I really was trying to find the right situation for me in both cases, I may just be bad at doing that. In the first case, I made sure that the company had been established for several years, and had actual clients and revenue (which were both very impressive tbh). It was a development team of 2, just the technical founder and one remove dev. I probably should have taken that as a red flag, as I discovered after working with them that the founder had cycled through many other devs on his team over the years and been unable to find people he works well with despite the business side growing. In other words, he was consistently finding/creating conflicts with his dev team & either firing them or like me they left.

The 2nd company was definitely more of a calculated risk, where I knew they had zero product & zero dev talent but thought it would be interesting to be the manager and put together a team of my own. I just didn't anticipate that after actually delivering, shipping and hiring a high performing team member (and unfortunately hiring one other team member we had to let go for performance reasons). I would then be let go rather than my contributions appreciated. Despite hearing from all sides we were on a great trajectory.

I've been reading WSB since yesterday and while I understand the outrage about blocking trading. They started blocking trading with $GME trading in the $400's, and a slew of redditors on WSB, Discord & Telegram pushing penny stocks. It started out a crusade against the hedge fund shorting $GME and quickly turned into rallying dumb money to pump and dump penny stocks. Looking at the direction things were going it seems like Robinhood acted responsibly in cutting off the buys of AMC, BB, NOK, etc. They're all stocks that have been propped up artificially in the last 48 hours based on the hype and attention generated by the Gamestop story.

No one serious thinks Gamestop stock is worth $400+. Robinhood cut off buying at the point when unsophisticated investors were caught up in a stampede to "stick it to the man." Seems like they did the right thing.

Did you read the article? It’s anonymous data about where tourists are in the city that only checks their cell phone’s country of origin. They are using it to manage crowds, not monitor individuals.

Doesn't everyone know you don't need React? That it's a choice?

That said, I was once a single page app skeptic but I now think React and Vue are great alternatives to HTML/templates that compile to HTML if you have a reasonably complex front end. Pre-React and Vue, in the Angular.js/Ember.js/Backbone era, SPAs were not in a stage of maturity that made it simple or optimal to use them as a primary front end. Today I'd say for a complex FE go ahead with React or Vue, if you have a very simple FE, definitely consider HTML/template-to-HTML as a serious option.

That's an interesting comparison. I can understand the argument that design patterns are just like learning another service or tool or library. But aggressive use of design patterns is taking a language we already agree on, say Rust or Javascript, and adding a dialect to the language that can easily divide the existing commonality we have within idiomatic use of the language. Design patterns just strike me as incredibly non-utilitarian, divisive and non-additive in a field that already struggles to find agreement.

I wouldn't say adding a service, framework or external library to your stack is as divisive for code readability as being a big fan of utilizing design patterns.

This is a brilliant distinction, that design pattern are meant to be descriptive rather than prescriptive. Because the problems I tend to see in the wild are when developers treat design patterns as prescriptive.

What's more or less understandable is a bit subjective. There are some things that are obviously less complex than others. Some things that are obviously more complex than others. And then a lot of gray area.

In my experience there is at least a faction of developers, myself among them that have a disdain for "design patterns thinking." Which I would describe as: spending a lot of focus learning various design patterns, then while coding actively looking for places where those patterns could be put to use.

In my opinion this is an anti-pattern similar to overuse of abstraction in simple cases before an abstraction adds to the understanding of the code itself, rather than makes the code more complex.

I've seen lists of common design patterns dozens of times, and occasionally recognize several of them as useful examples of things I've actually done in the past or my colleagues have done in the past. But it seems to me "learning design patterns" as an end is encouraging the destructive side of design patterns where you learn something and eagerly look for a use for it.

Once you get past writing a language idiomatically, is a list of design patterns a good thing? It is an obvious negative for code readability because it reduces the number of people who can clearly understand your code from Rust users to Rust users who also memorize design patterns.

When are design patterns useful? And how are they useful?