That's probably why in the US nobody put their cart back. They would do it if they had to get their coin back. Again, to fight laziness, go for the wallet!
Nice to see it being mentioned again. I have been using it for a few weeks no and it definitely helps in reducing the amount of time I spent on HN. The UX is also really nice, especially the ability to collapse comments much faster than regular HN. Good job!
Great job! It really fits the way I consume HN which is just once per day usually.
I like the outline.com article style, and also discovered outline.com in the process.
I am not a huge fan of the layout for the comments, it feels a bit too big for me and a bit hard to follow along, as it switches between authors and so on, but that might just be a personal preference.
You should probably consider making it open-source as it is definitely the type of project I would like to contribute to!
It might just be me but enabling the option and clicking and the recording button just attempt to reload the page and I get a blank page. Not sure what is supposed to happen.
Is using react-native for Web better than having react & react-native for your UI and nicely separated business logic that is reusable for both?
If you use react native for Web, does it mean your UI will look exactly the same whether it is on the web or mobile?
Advice: Skip straight to the situation paragraph as anything before that isn't about the DocuSign integration, not sure what the first section brings to the whole article.
This is interesting. The whole having to specialize thing has been scaring me a bit lately as I really do like the fact I can be jumping back and forth between the paths when working. I have been told that I should find something to specialize in as most of the companies require you to be specialized and there is no place for generalists anymore, which sounds weird to me.
So are you a specialist in anything? It seems you have close to a 20-years career so I was either lied/misguided or you have expertise in one of those domains?
It strongly depends on the company you [want to] work for - also depends on what you actually enjoy.
At a smaller companies go for breadth; there's only a few of you. Larger companies prefer depth - but! at larger companies there can be more projects for you to have your fingers in.
Depending on specialisation, work can be rare but more rewarding - but you can also paint yourself into a corner with things moving out of vogue. Silverlight/flash, Ruby, VB, etc.
I've been at it since the 90s. I'm a generalist, mastered a few areas, and worked in. It gives me choices - I where to go for a web-based job, I'd call myself a web developer and not boast no much about my C knowledge.
At my current job, most the skills I provide aren't necessarily rare, but the combination of them is - where it could take 2+ people to replace me (excluding productivity).
The balance is to specialise enough in a few areas, but not be a "jack of all trades; master of none"
I am an avowed generalist, and I will die on that hill. Because being a generalist programmer is the greatest! :)
Like I said above, code is code. Code is just syntactic sugar around concepts, and concepts transcend languages and environments. Understand the concepts and you can pretty easily jump around just about any programming environment, from front end to back end to desktop to mobile.
It's kinda weird to me how many people think these things are so different when really they're not. Yes, every language will have its quirks and every context will have domain specific knowledge and tooling. But they are more similar than they are different, and once you grok the similarities, the differences become easy to recognize.
I've seen so many things (languages, toolkits, environments, etc) come and go over the years that I refuse to be pigeonholed into one specialty because they always change, often without warning. Ask a Flash developer how they feel about that today - in one day (the day the iPhone was released) that whole industry collapsed. The great thing about being a generalist is that you can move on, jump in and do the work that needs to be done, no matter what that work is or where it is.
Every so often something genuinely new will come along, that requires some learning and understanding. The container ecosystem are a good fairly recent example of that. But as a generalist, it doesn't look hard or magical to you because it's just something you haven't learned yet. You're prepared for that and you have the understanding to know what you need to know. You also know your limits, and the things that do (or don't) interest you and can adjust the arc of your career appropriately.
I routinely work back and forth between front and backend every day. That is a normal day for me, I love it and and I would not change it. Occasionally I'll lend a hand on an iOS app (that we're about to migrate to React Native as it happens) and maintain some internal Mac apps as well as writing my own Mac apps for fun. I've also run a side consulting business for several years to keep my skills fresh where I tackle everything from DevOps/server maintenance/cloud migrations to frontend/backend to desktop and mobile development. Basically whatever itch I'm feeling at the time.
Concepts translate pretty easily and, where they are different, as a generalist you accumulate enough experience to know what those differences are. And if companies want to divide their jobs into "front end" and "back end," that's fine, because you have the knowledge to apply for either. :)
A lot of people in this thread are really selling themselves short. They know more than they realize and the "other side" of the stack is not some mysterious magic that requires years of intense specialization. It's just programming. Same thing we've all been doing for years.
I wish HN would notify me of answers for my comment. Yes, I totally share that mindset with you.
I actually use pretty much the same thing when helping people starting their programming journey.
'There is so many things to learn I started with Python but there is this and this and that'
A language is just a language, the principles and your ability to translate problems to code is what is making you a programmer.
In addition, as someone used to working on small teams, specialization seems inefficient.
If you only have 3 developers, it doesn't make much sense to have one backend, one frontend, and one dev-ops. Are you always going to have exactly equal amounts of work for all three to do each day?
But apart from that, it also seems so much easier to divide up work by feature without stepping on anyone's toes. Like, you code search, I'll code chat. Not you code search backend, I'll code search frontend. That increases overhead and coordination.
And then, if your frontend is heavy on JavaScript, there's often a lot of similar code between frontend and backend. Validation is a classic example. A more extreme example might be a browser game using WebSockets and lockstep simulation. The browser and server might share most of their code. It would be absurd to split all the developers into frontend and backend in this case.
Maybe it's time to put our old "webmaster" hats back on.
Generalist or polyglot developer still doesn't fully capture the broad scope of knowledge you can call on beyond cutting code and may have lost any of its negative connotations over the last 23 years.
Yeah, one of my favorite things is to pull something from a domain that has parallels in another. What appears like magic is just having a broader exposure to various concepts and domains.
Being thorough and highly detailed is definitely something that I praise with the colleagues I have doing it well. Someone taking time to write good PRs and maintaining documentation is definitely more useful in my book that a fast coder. Good documentation reduces the bus factor by a lot, and make someone a team player in my opinion.
