I concur, and add that HN could really help OP by complaining about random stuff here. Just complain about the first thing that comes to mind that's been bugging you, OP will really appreciate it!
I concur, and add that HN could really help OP by complaining about random stuff here. Just complain about the first thing that comes to mind that's been bugging you, OP will really appreciate it!
I hate to use labels but to believe anything else is to be a climate change denier.
1- https://en.wikipedia.org/wiki/Six_Degrees:_Our_Future_on_a_H...
The post goes sufficiently viral that it gains the attention someone within [large entity] who can actually do something about it. This is a terrible model. It's not really a model at all, it is the complete absence of any working model.
Make something that enables individuals to tell large entities that something needs to be done. Effectively turn input from many into a list of meaningful, actionable items that get delivered who have the capacity and desire to do something about it.
How is that a startup? I dunno, maybe there's a small part of that big problem that you can start tackling. Maybe it has to do with some facet of the economy you're improving/making more efficient, maybe it has to do with influencing policy. That's for you to figure out.
Find a big, big problem, and then look for a manageable chunk that your team can execute an idea on. You're in this for the long haul, right?
People that use a car are not "typically looking to increase the rate of global warming and actively pollute the environment".
Using a car is a means of getting from place A to B, in the process however, you create a negative externality (i.e. pollute the environment).
When you create a startup you generally want to solve a very specific problem X at a grand scale, when you are able to do this while making some profit/growing in value you inevitably contribute to "inequality" as an externality.
Paying $10 to an SMB owner instead of $100 to Bill Gates et all reduces inequality, it doesn't increase it.
Would have hoped the last year would have shook you all to your senses
I'm annoyed I feel the internet is turning more and more hateful.
I'm annoyed writing and fixing tests takes half of my time when writing code.
I'm annoyed business people only see the difference of salary asked and not what experience brings when having to choose between a junior dev and a senior one.
Then just don't write tests and wait for what happens, when you find a bug 6 month into production. ;-)
I would've never done this without TDD because I dreaded to have hidden bugs sending washing machines to the wrong customers.
I've started writing only integration tests, this is cool because most of the time it only breaks during refactoring when there actually are regressions. I've also made myself a chrome devtool to record my interactions with browser and generate capybara tests out of it, so it's quite fast to write and rewrite, it never happens anymore that I think "oh, maybe that change is not worth it".
But the thing is, this only works for apps/features having a web interface. I do more and more system programming, and I have no idea how to do integration testing on this (I think about using docker, but this would be even slower than piloting a browser).
So yeah, anyone who can solve the tests burden problem while still making code as robust, I'm interested.
(btw, you'll still find a bug in 6 months in production with 100% test coverage ;) )
I'm also not a fundamentalist when it comes to TDD. It really depends on "What can go wrong?" and "How much time does each route costs?"
The other day I showed the guy I'm mentoring how to write tests in go to test some Go middleware code for HTTP BasicAuth. This was some example code he found on the internet. And guess what, it has a basic logic flaw where it doesn't test for correctness of user AND password, but for correctness of user OR password.
Using code like this and not writing tests is really stupid.
When I was in university, I also read lots of papers on TDD. There are many "we had 20 students trying to solve a 2 hour problem with and without TDD"-papers and only a few "IBM and Microsoft used TDD and no TDD to write hardware drivers, these are the results" papers. Guess who I'm trusting more.
The answer of pro-TDDs was that you always benefit it, even when already experienced. I agreed with them, back then.
I don't remember seeing those about IBM and Microsoft, though. What were their conclusions?
Nowadays, I do what I jokingly call "documentation driven development", as a follow up for "top down development" that cucumber and the likes introduced. I'll usually first write about the problem I'm solving, then generally write about how I solve it, then write about components needed to implement that solution, then what those components do in details, then I write function signatures, and I stop there. I give it a month going back to it from time to time and I always figure out problems with it.
Refactoring that is awesome : no tests to change, no application code to change, it's just manipulating pure architecture, and it's incredibly fast to change while still being able to keep everything in mind. Careful planning is kind of replacing for me what TDD used to do (for the part about designing proper architecture ; I do integration testing for the part about catching regressions).
But really, I feel today that the methodology doesn't matter much : agile or not, TDD or not, this or that, whatever. What matters the most is people. The same methodology will have opposite results depending on who is applying it. I guess some methodologies will be better than others for learning programming, but I have really no clue how to measure that :)
My phones and laptops are small enough and lightweight enough.
Making them bulletproof is too expensive. But making them easier to fix, documenting the process and authorizing repair shops would do be great.
PS: I don't need to be able to hot-swap parts.
PPS: pro models from Dell and HP at least are often quite easy to disassemble and fix and I think you can often source parts from eBay for years after you buy them.
The real problem is that phones depreciate so quickly that replacement parts (especially displays - Samsung LED screens etc are notoriously expensive) are often more expensive than buying a new second-hand phone on eBay unless you're willing to go down the route of separating bonded LCDs from glass/touch sensors is economically viable but that is much more difficult to do right, even with the right equipment (temperature-controlled hotplate).
Just replaced the screen on my Mi Mix for about $100 plus an hour or so of my personal time.
I'm projecting from impressions I'd made since the Mac book pro became harder and harder to modify and upgrade. I'd constructed a faulty assumption about the repairability of iPhones.
It's never been difficult for me to find someone to repair one of my old iPhones in the past, I just quit on iPhones last year and feel somewhat disappointed with them since the v7s. (I am a fairly recent switcher to Android.)
i like the idea - we just need a new tag
HN Pain Point:
that seems more like it