vpfaulkner
Blackbird builds web, mobile, IoT products for startups and innovative companies. We work on interesting, greenfield projects, and rely on small, veteran teams who have lots of autonomy. Everyone is a remote contractor, and our work culture is low-drama and highly collaborative. No pointless meetings, no bureaucracy, no egos and lots of time spent building things. Projects typically range from 3-12 months and usually require full time hours (35/week).
We’re looking for senior full stack engineers / CTO consultants / data scientists. We value engineers who are strong technically as well as great communicators. We work with lots of freelancers who appreciate the steady, interesting work.
Our typical stack is TypeScript, React, Postgres, and AWS although it will vary project to project.
If you enjoy moving fast, working with great engineers, and building something from the ground up, you’ll fit right in.
If interested, reach out directly to me at vance [at] blackbird.us with your resume, link to your LinkedIn, and a small blurb on why you think you'd be a good fit. Must be based in the USA and have 5+ years of engineering experience.
Blackbird builds web + mobile apps for startups and innovative companies. We work on interesting, greenfield projects, and rely on small, veteran teams who have lots of autonomy. Everyone is a remote contractor, and our work culture is low-drama and highly collaborative. No pointless meetings, no bureaucracy, no egos and lots of time spent building things.
We’re looking for senior full stack engineers / CTO consultants / data scientists. We value engineers who are strong technically as well as great communicators. We work with lots of freelancers who appreciate the steady, interesting work.
Our typical stack is TypeScript, React, Postgres, and AWS although it will vary project to project.
If you enjoy moving fast, working with great engineers, and building something from the ground up, you’ll fit right in.
If interested, reach out directly to me at vance [at] blackbird.us. If you have an hourly rate please include that + any other freelancer / agency work you’ve done.
Website: https://blackbird.us/
Blackbird builds web + mobile apps for startups and innovative companies. We work on interesting, greenfield projects, and rely on small, veteran teams who have lots of autonomy. Everyone is a remote contractor, and our work culture is low-drama and highly collaborative. No pointless meetings, no bureaucracy, no egos and lots of time spent building things.
We’re looking for senior full stack engineers / CTO consultants / data scientists. We value engineers who are strong technically as well as great communicators. We work with lots of freelancers who appreciate the steady, interesting work.
Our typical stack is TypeScript, React, Postgres, and AWS although it will vary project to project.
If you enjoy moving fast, working with great engineers, and building something from the ground up, you’ll fit right in.
If interested, reach out directly to me at vance [at] blackbird.us
I suppose you could say the net value of some code = contribution to business objective - maintenance cost.
This also implies that code could have a negative value depending on its business value and maintenance cost
Based on the other responses, it seems like we can mathematically model these phenomena very well and make very good predictions. However, when it comes to explaining why these phenomena exist in the first place, we are like a medieval doctor trying to explain why antibiotics work.
To a non-expert it can be difficult to separate which theories lay on solid ground and which theories are highly speculative.
Obviously people would prefer, for example, a YouTube that is free, without advertisements, private, etc. But, my point is that developers tend to have different preferences than the general population and, thus, we shouldn't be surprised that the Internet has evolved in a way that reflects those differences.
However, to say, "most people will come to the same conclusion I have given enough time and evidence" seems a little naïve, and overlooks the spectrum of preferences that people have for the various things developers consider "hostile."
For example, while a lot of developers (myself included) love the minimalism of, say, Hacker News and hate the bloat of, say, nytimes.com, I think it's unfair to call nytimes "hostile" to the user. Frankly, it doesn't grate the typical user that much and the decisions made by NY Times designers/developers reflect that reality.
I think a similar argument can be made about privacy. Some people would pay for a product that is private and without advertisements; others are fine with the tradeoff.
If that is the case, then I feel less comfortable with the idea that this is simply evil corporations commoditizing users.
Rather, I think the more nuanced explanation takes into account the fact that the web's users today (now at 5 billion people) and the people shaping its content (eg marketers, designers, business people, etc.) simply have a very different set of values than those active at the web’s infancy.
In other words, perhaps it has become democratized...it's just that that means it looks very different than you would prefer it.
I also agree that too many log statements can actually be counterproductive by providing a lot of noise.
But the idea that logs have no value is silly. Every developer writes bugs and will run into situations where the code is behaving differently than they thought in production. Being able to follow the logs to understand what happened is extremely valuable.
However, the issue is that the traditional division of concerns is more difficult to maintain in today’s web apps. Compared with web pages 20 years ago, web apps today are dense, interactive and complex. You might have dozens of UI components in a single page, each with their own piece of state, business logic and styling. Moreover, state, business logic, and presentation are oftentimes tightly coupled by design: eg, dragging this slider changes its shading using a complex algorithm.
Therefore, it’s becoming more advantageous to decouple individual ui components, each with their own state/logic/styling, than it is to, say, stick all of the state your web app deals with in a single place.
In other words, it makes sense to encapsulate all that code related to that crazy slider in one place, even if that includes state, styling, algorithm, etc…
What if social media platforms required all minors to have their account associated with a parent account? The parent could monitor activity, institute time limits, etc.
- Styles are global
- Styles are targeted via brittle, untyped, and opaque "magic strings” basically. This means mistakes are more likely to be caught at run time than compile time. Eg, I wouldn't get a compile time error if I did `position: oops` or `class="oops"`.
- Styles are often "far away" from their target which makes mistakes more likely; ie this deeply nested HTML element in one file is coupled to a deeply nested style sheet in another file
- It is easier to perform complex manipulation of styling if it is made up of JS objects. Eg, if I wanted to do math or I wanted one style to be a function of another (eg `marginLeft: PAGE_MARGIN`)
That being said, I’m sure there are some better ways of doing traditional CSS since I last tried it that I’m unaware of...
As far as the performance trade off, I'd love it with styled components did not come with this but, at least for my use case, it is usually worth it
This last project we’ve actually been running true E2E tests by spinning up the backend in GH actions (looking for a branch with the same name or falling back to master), seeding it, and making snapshot-style assertions about the UI. It’s more complex and slower but tests a lot more code now that the backend is involved as well as the API layer. It has helped a lot in major refactors.