HNHacker News
TopNewBestAskShowJobs

kmclean

498 karma · joined May 9, 2016

Canadian web developer from the East Coast. Love travelling, sleeping, yoga, knitting, violin. kirahowe.com
submissionscomments
kmclean··on Tim O’Reilly makes a case for why venture capital is starting to do more harm
> It’s part of the structural inequality in our society, where we’re building businesses that are optimized for their financial return rather than their return to society.

Isn't this the whole problem? If people cared about society more than money it wouldn't be a problem to invest or take investment money, because you'd all be working toward the same goal of maximizing returns to "society". The problem is greed and selfish pursuit of wealth by certain kinds of people who see that as a worthwhile purpose for their life.

kmclean··on How many of you know that the team is working on something that no-one wants?
I've had a very similar experience. I'm surprised at how little so many managers and investors understand AI.

They talk about it like it's some sort of panacea that will make a company automatically grow 10x. Then you ask them what they actually want you to build and... Crickets.

kmclean··on How many of you know that the team is working on something that no-one wants?
> Instead, they are usually focused on making sure the team is building what their boss thinks should be built.

This rings so true. I vowed to never again work with companies with non technical leadership for this reason. My career so far has mostly been building features nobody wanted for people who are trying to impress management and/or VCs.

> The less technical the dev manager is, the more likely they are to be ignorant of technical debt, that is until customer escalations become politically untenable. This life cycle is why the engineering VP job has about a one year lifespan at many companies who run Idea Silos.

I've never heard of this concept of idea silos before. It makes so much sense. At my last company it was even worse. I had 4 managers over 2 years, yet the more senior management gave the VP of engineering free reign to make whatever changes he wanted (yes, they were all men), so the system was a cobbled-together mess of half baked features as a result of each manager coming in trying to make sweeping changes to show off their "scrum" skills.

> Engineers are problem solvers, and if the primary problem becomes delivering Something™ that will pass QA by the Date™, they will, with enough pressure, solve that exact problem.

Ahhh I can't even handle how accurate this is. You should have seen the spreadsheets and meetings we had about sizing and building roadmaps. The entire engineering department's job became keeping managers at bay by producing roadmap items on schedule. There were meetings upon meetings about "metrics", which were just numbers we made up but put into a fancy spreadsheet, because doing calculations on made up numbers makes them appear more legitimate than raw made up numbers.

The majority of the effort of our department was wasted on features nobody wanted. They sounded impressive and apparently were cool enough to keep investors satisfied. This company also went to great lengths to re-brand itself as an "AI" company, whatever that means, even though none of the people in charge had the slightest idea what AI was really capable of or how it would benefit the business.

The worst part is that it took so long for me to realize I was wasting my time. After the third major feature I delivered to be used by absolutely nobody I realized we were out of sync with reality. I thought I had made this great discovery and was almost excited to bring it up because I thought it would be a great opportunity to change to do better by our customers. Instead I was met with a response that essentially amounted to "shut up, know your place, and give me code", which is when I realized I was really just a cog in this machine designed to get engineering VPs bullet points for their CVs, and left.

kmclean··on How many of you know that the team is working on something that no-one wants?
This feels so true! I had a similar experience.. spent 3 years working for big US companies, completely focused on whatever trend would impress investors the most with no one giving any thought to what might actually be _useful_ for people who, you know, actually give us money.

Now I work for a small company doing very niche work and I don't think I could love my work more. I mean people do use our software, but there's no VC funding so no pretense of needing to hop on the latest bandwagon. It's just so much better.

kmclean··on Amazon added a non-compete after the employee entered the U.S. on an L1B visa
Yeah you're probably right. It's a bit depressing learning about the way those who actually make a business worth anything get treated, though.
kmclean··on Amazon added a non-compete after the employee entered the U.S. on an L1B visa
This seems really shady. It seems to imply it's legal for companies to restrict what you do after you don't work for them anymore? Any historians around? How did the US get to a place where employers have near total control of their employees, even after they're no longer paying them?

That just sounds bad. I've also heard of contracts that essentially prohibit side projects or moonlighting. Are software developers not aware they don't need to accept these restrictions to make a living? I guess maybe companies impose the restrictions under duress like in this story. Still, I'm surprised companies with such unethical employment practices can manage to hire anyone.

kmclean··on Forecast, don't guesstimate your software projects
> And here’s the brutal question: what good are estimates if they hardly ever align with reality? You could have spent that time on building software.

No one has ever been able to answer this question for me.

In my experience the accuracy of estimates is highly variable. Experienced developers who know each other and the system they're working on well tend to offer more realistic estimates, but even on the most smoothly run teams it's still fundamentally guesswork.

From my perspective it seems like the only real effect of estimating units of work is making developers resent people outside their team. Sure, it gives product people a number they can say when they get harassed about when something will be done, but it's no more accurate than one they could have just made up on their own.

I don't think I see any fundamental difference between estimating and what this author calls forecasting in this respect. It does seem like generating these metrics could consume less time than meeting to make up estimates, but it's not obvious to me that it always would be.

What real value does this add to any business? Any product or business people here? I'm genuinely curious what the purpose of estimating is. It feels like nobody is winning. Product and business people get annoyed by missed "estimates" because what they really want is to know the future, which is impossible. Developers resent being asked to predict the unpredictable. Not to mention I don't know any programmers who prefer talking about doing stuff over actually doing stuff -- all the meetings that come with management styles that include things like estimates feel like an enormous waste of money.

Who is winning here?

kmclean··on REPL Driven Design
Just to be fair, I don't think many practiononers of REPL-driven design would consider it a replacement for tests. It's an alternative workflow to TDD, yes, but the idea is that you still write comprehensive tests, they're just usually at a higher more system-y level than the ones you get from TDD.
kmclean··on What a typical serverless architecture looks like in AWS
That sounds really appealing. I really love the sales pitch for serverless stuff. I think I've probably just been exposed to a lot of really advanced ways of setting it up for a big project. It seems complex.
kmclean··on What a typical serverless architecture looks like in AWS
That looks really complicated to me. What's the advantage of setting up a system like that over a typical server, i.e. with most of that stuff handled by one server, writing code to coordinate between a few external things (like maybe auth0 and a DB)?
kmclean··on Ask HN: What do you do online?
Mostly waste time browsing HN, reddit, and the various places those lead.
kmclean··on Ask HN: Production Lisp in 2020?
Have you considered lisp dialects? I've been working with Clojure/Clojurescript for a while and it addresses most of those concerns. It's been a real pleasure to work with.

- There are lots of high quality libraries, but you also have access to the entire Java and/or Javascript ecosystem with very easy interop

- Not too sure what you mean by "community coordination", but I've found the clojure community to be exceptionally friendly, welcoming, and responsive. The core team is active and I've even had some questions answered directly by them in slack!

- There is some tooling built and maintained by the core team that makes managing dependencies painless

- There's a library (transit) that's widely used and well suited for marshalling data in and out of a clojure app. There's a library that's part of the core which implements the CSP (communicating sequential processes) concurrency model, similar to Go. It works in both Clojure and Clojurescript and is a very sensible way to manage async operations in a system.

- GC is managed by the JVM (for clojure), which is state of the art

kmclean··on Coming to Chrome: a new way to use tabs
Are these separate containers (like Firefox containers) or just some UI to visually group certain tabs?
← PreviousPage 3 of 3