Probably as a hobby you will not be able to write an analysis that will get published in a paper, but there is a lot of descriptive analysis out there that can be very interesting.
I did have a statistical background before starting at Apple however. Most of my projects were self-taught and done as self-research (I am not a fan of the take-a-million-MOOCs strategy everyone likes).
Brb, building HN for crypto.
1. Mechanics, how well can you navigate and type using the tools you have available. To practice this an easy thing to do is formatting your code without any automatic formatting. In vim for example, this helps you learn the commands.
2. Reasoning/problem solving. This one is harder to practice and really requires experience. Always have a project and spend time trying different solutions. A nice characteristic of software is you can usually just undo if something was wrong, so don't be afraid to experiment.
3. Research- it's safe to assume someone else already solved a problem. Use google to find their solution and read how they solved the problem. Never be afraid to open up someone else's code.
It's the equivalent of writing out notes by hand from a school textbook instead of just photocopying the pages... some how the process of actually re-typing it out causes it to stick in my mind better. And then later, when you're really "in the zone", you don't break your focus by needing to keep referring back to the book, it's already embedded in your muscle memory and you just keep plowing away.
An incomplete lost: 3D graphics programming, write a compiler or interpreter, write an emulator (Gameboy is popular), write a web server starting from a socket, learn a new language paradigm, grab a raspberry pi and do something with gpio, find a friendly open source project and close some bugs, and so on.
I'm an advocate of the "T shape", where you are deep in one or two things ("pi shaped") but have dabbled in lots of things.
I would not that while katas as others suggest are not bad, they are usually count for just one skill. You may learn a lot of clever tricks and some useful math, but what you get out of them will plateau before you get to the end of the katas set.
Write prototyping code that solves an existing problem as nearly as you can manage, and then figure out how to improve it on one or more metrics:
* smaller SLOC (automatic programming, data abstractions, etc)
* better portability, fewer dependencies, simpler build processes
* better throughput, latency, or resource usage(memory, storage, bandwidth, energy)
* eliminate one or more classes of errors(e.g. off by ones, null dereferences)
* better user interfaces, better documentation and accessibility
* more efficient development of the prototype
* better working environment (workflow, tools and knowledge of the tools, automations for convenience)
Oftentimes, you can make one change and improve several metrics. Other times you sacrifice one to get others. There are bad tradeoffs like code golfing or premature optimization. Having the prototype already in hand is crucial in all cases since it gives you a spec to bump up against when you're at risk of falling off track. If you're more daring this can take the form of an existing shipping codebase.
I am not entirely sure deliberate practice works for programming. I've been following Anders Eriksson's work for 10+ years, and it seems most applicable when applied to domains that have a history of training. Want to learn how to sing really well? You can probably do it. Want to be the best basketball free-thrower in the world? Probably.
It's the lack of a body of trainers and training that hurt, because deliberate practice talks about having quantifiable goals and the ability to compare how you did it versus how it's supposed to be done. E.g. have a trainer in golf means the trainer can critique your strike.
If I ever figure out deliberate practice for programming, you can bet for damn sure I'll write a book.
>the effort to increase domain expertise while engaged in routine work activity.
They then go on to give four types of exercises to focus on:repetition, timely feedback, task variety, and progressive difficulty.
Deliberate practice is about working on your weak area till you're no longer weak in that area.
You MUST perform a retrospective on all your projects. Ask yourself what you struggle with often, what are your pain points? Identify them, then work on them. The mistake I often see is that most developers create more problems for themselves by attacking multiple problems at once. If you have XYZ problem, and you decide to use a new language, a new framework, a new cloud service/API, a new DB and a new design style you have never used before. You will never be sure your pain point.
What you must do in this world of too many choices is LEARN TO CONSTRAIN. Pick a language, DB, framework, etc that you know. Nothing should be new to you but the problem. Yes, it's true that your existing tools might not have everything you need. LEARN TO BE RESOURCEFUL. With that said, attack the problem, if you have any issues, it will be obvious and apparent.
Let's say you have a great project you understand through and through and you wish to learn a new DB. Keep all things constant, rewrite your old project and the only thing that should be new is the DB. Repeat till you master the DB.
You must limit your problem to ONE and ONLY ONE at a time. This allows you to measure and correct faster if on the wrong course.
The sketch is a standalone project that embodies what I want to understand. It could be React with a basic router and a test framework. I'll iterate on that. Sometimes several times. Then I integrate into the projects I'm working on.
Usually this is verifiable in some form. Being reliably testable is one. But others could be micro-benchmark performance. Occasionally the aim is just to re-write in a different language.
In the future, if I wanted to make a structural change (e.g. a different router) - I'll go back to the sketch and make the change. Sometimes I also do a sketch from scratch. However, I find working on the original sketch informs changing the production code a lot better.
In "deliberate practice" terms that's a very macro-level approach, but it's a balance that's worked for me.
- Deliberate literature practice involves as much (or more) reading as it does writing. Tangentially, code review is an important way to both learn how other people express ideas in other ways, and to learn new features and tricks to express yourself in a given language.
- Deliberate practice in mathematics begins with rote memorization, and later with repeated application of algorithms. So practice could first involve typing common algorithms, including brackets and other grammar, until they (e.g. a FOR loop) can be typed from memory. Or possibly automating this step, and practicing using the automation. Later practice could involve repeated application of algorithms - possibly algorithms of your own making.
Answering questions on Stack Exchange?
Watching marginally related recorded talks at conventions?
Focusing on the thing for an extended period of time while exploring new territory?
The muscles you're wanted to exercise are pattern recognition and lateral thinking, all in the problem solving family.
So, find a problem, them solve it.
In understanding the radical designs and patterns that great coders have used and argued about, you'll see you own code style change, even unconsciously.
Practice for algorithms could mean doing a lot of leetcode/interview style algo problems.
Practice for working with large codebases means practicing reading/understanding code quickly. So maybe picking a large scary open source project and trying to make a contribution.
Reinventing wheels like andreasgonewild is the most useful and fun kind of practice IMO. Pick a cool technology and make it yourself from scratch. Maybe in a new area you know nothing about. A distributed KV store? A stack-based programming language? A code formatter?
If you develop something big like that, you will surely exercise all the muscles it takes to develop something. Reading too many tutorials or watching too many videos is narrowly exercising the "learning" muscle. Solving algorithmic puzzles is narrowly exercising the "CS fundamentals" muscle. But the best workout to prepare to chop wood is to chop wood.
Next time I'm much smarter, seek partnerships and even better if your product is an upsell, then you can have others sell it for you
It's surprising how many of us are always looking for new customers, when sometimes, contacting people who you already have a relationship with works best.
Even if it's your first business. Maybe you know a few folks from your previous job, an internship. These people already trust you, know you and interacted with you before... the easiest way to get your first customer, I think, is through the network you already have.
Browse through your phone and email contacts. Your first customers and users might be sitting in your pocket as we speak :)
- identity service
- payment services
- 3D positioning data, including 6DOF
- hand tracking and object tracking (AR)
In terms of future-y stuff, I can see some sort of blockchain integration, like CloudStorage as an IPFS version of LocalStorage. That would potentially need to dovetail with the identity and payment stuff.
I suspect as we get deeper into AR times, some kind of device-relative geo services will need to be necessary. Like, give me a list of services that are within 1 foot, 20 feet, and 1000 feet respectively.
Personally, I also think the browser is ready to make the leap to a kind of raw metal relationship with hardware. ChromeOS is an example of this, Firefox OS was an attempt. I'd like to see more specialized OS's that can boot hardware directly to the web. The security models on Mac and Windows are slowly approaching something more like the web anyway, where apps run in a sandbox. Web pages have been doing that forever, so it seems like a good fit for a security-conscious OS.
A mobile headset would be a good opportunity for such an OS to differentiate itself. Which leads me to...
The other huge opportunity I think is in web "filters". We've gotten to the point now that there's just a lot of crap out there, and with ad blockers and readability filters we've started to dabble in a meta layer. I think a future web browser will go full meta, where by default you don't see the actual web page, you see a thumbnail and a bunch of views on the data in that web page, and you only dip down into the giant messy interactive ad-riddled view if you want to.
Past endeavors include the whole space of web annotation, semantic web, etc. Not sure why none of that has taken off, but seems like something that will find product market fit eventually.
One of those "filters" could be an AR filter. Take a web page and map it into AR space. Also VR. Add avatars of other people around the content. But there should be a whole marketplace of filters, language translation, low power filter, etc. Opera was doing some version of that. You could have political filters too. "Block all misogyny", "Add Fox News' take", "Keep everything tidy and German" etc.
A lot of this marks a general transition from a site POV to a user POV for the browser.
If anyone wants consultation on any of these ideas, I'm available for hire. :)
I'm sick of having to choose between either Firefox, Edge, or a thousand Chrome knockoffs. There needs to be more diversity.
It's quite obvious that they will all implement next JS standards, with some experiments here and there.
They will add API access to more hardware like VR helmets, controllers, maybe even USB devices (which would be great for web hardware based security, like 2FA).
Probably voice control and typing (like on Android).
Probably automatic translation (not just by Google).
Built-in free VPN (limited obviously) and TOR would be nice.
Once things settle down into familiar pattern and you actually have a good idea of what your workload will look like down the road and what specialists you actually need (as oppose to imagine that you might need), then you can start hiring specialists.
Edit: That being said you should have someone responsible for each part and you can split your team into primary front-end and primary back-end based on their relative strength and preferences. However it's important that everybody has the necessary skills to work on all parts of the product in the beginning.
I'm old enough to have experienced at least 2 full thin-client-fat-client cycles and I'm certain the current one won't be the last (at least it seems to have been a recurring pattern since the beginning of modern computer science).
While the front-end / back-end paradigm might make some sense right now because the technologies used for each of those layers conceptually seem to be quite different from each other I doubt it's really that much of a benefit. On the contrary, it might even be detrimental to effective software development:
I'm not in the business of creating either front-end or back-end code. Neither is useful without the other. I'm in the business of creating value and solving problems with software. Depending on the problem at hand this can involve different tools at varying degrees.
Focusing on just one tool or layer can lead to a potentially harmful mindset. A mindset in which you just throw your part of the work over the wall thinking that it's not your problem anymore.
The arguable benefit of having specialists churn out stuff in their respective layer more quickly than a generalist would quite likely is offset by communication and interface overhead: The difficult problems in business applications nowadays mostly arise at their boundaries. Software development for the most part means communication.
One mistake that gets repeated over and over again is the protocol that is too chatty because the people involved like the idea that, like subroutines, operations should be composed out of smaller operations. Trouble is that distributed calls take 1000x or more longer than subroutine calls and are billions of times less reliable.
Without somebody looking at the big picture, what you'll learn the hard way is that performance, reliability, and security are holistic properties of the system which you won't find localized in any one place.
Doesn't matter that I rolled our whole architecture and infrastructure, did all of the ETL work, can handle security, web accessibility & design, and basically run point on all projects. I use basic, unsexy, reliable tools.
My theory is that most backend developers claim to be "full-stack" in order to get the job even though they really are much more focused on backend stuff. This is because its very hard to learn ruby/python/php/java for web development without learning html/css. Project Managers like having full stack jobs only because they think that can just get somebody to "do everything".
These days development is more like "make the site be a single page app with a responsive mobile-friendly design" (frontend - angular/react/ember...) and make it process data from the user and send it off to external apis and integrate third party libraries (backend - rails/django/.net...) and have a version controlled and automatic way of deploying the code to a multiple servers behind a load balancer (dev ops - chef/puppet for example).
As with any technology, the more advanced it gets, the more need there is for practitioners to specialise.
In principle, the world needs more between disciplines experts and you can see it as a universal trend.
At smaller scale, strong full stack developers can get quite a bit done in "team of one" mode -- perhaps more than two specialists who have to spend a fair amount of time thrashing out interfaces.
A secondary problem is that any time you have an interface and people who can't clearly understand what happens on both sides of it, you end up having integration problems. And meetings to discuss the problems. And proposals to solve the problems. And disagreement on who should solve the problems. And future arguments if the solutions are wrong. "Communicate with an appropriate formalism" is the probably the hardest part of software; why would you introduce that if you don't actually have to?
This is a less cynical take than a popular post of mine a year back , in which I say:
> The 'full-stack' trend is a reflection of rising, dare-I-say unrealistic expectations, one which the author supports by their recommendations in their blog post. By perpetuating the notion that the only 'true way' to be a good developer is to structure their lifestyle around understanding implementation details behind all the layers of a modern tech stack, they place an unnatural reverence on the mythos of hackerdom while ignoring that software development is not solely a creative pursuit.
> As it stands now, 'full-stack developer' is a euphemism, which in hip new places means 'we want you to live and breathe code, because you will be given vague requirements and expected to deliver the entirety of the solution from the bits moving across the wire to the UI espousing the latest visual design language in less than a month', and in established places means 'we want an infusion of new blood to bring sanity to some legacy code and we're counting on you to debug and fix everything by yourself'.
Technology also evolves too fast, and a company formed just by specialists will face problems with technology and software engineering processes changes. Having just specialists on a such ever change area is not a good deal. The best is to have a mixed team, formed by specialists and generalists, and in a perfect world, a good organization should be made of men, women, young and old people, natives, foreigns, etc. It's like a sailing crew, everyone is (or should be) really good doing something.
In this ever change world of software building, when hiring a specialist you always think: "If tomorrow this job doesn't need to be done more, what this specialist will do to stay with us?"
All of this is just my opinion, my personal theory. I made it up working 10 years with software engineering and development, and recently bootstrapped 3 companies, and the last years I'm studying administration.
That isn't to say this isn't a necessary evil sometimes. Security and mobile development are two simple examples that come to mind of dedicated specialists that many organizations have.
When it comes to generic development, it is beneficial for one person/team to own the entire stack because often the domain specific problems are where the complexity arises, not in the frontend/backend split.
I don't know why' you be an either when if you had just learned both you can always work in a company that silos people off. Even though I've always seen it as way less effective.
Also I think our job is often just 75% "here's a bunch of information, figure it out" so it doesn't matter what the material is because you're constantly seeing new stuff. Know a lot about a little, and a little about a lot. It's good to have a focus on something but you should be able to navigate every step of the process, even if more slowly than the person who usually does it.
- starting businesses/(relatively) small businesses that look for someone with the broadest skills possible, this way you employ fewer people to get the job done and have a MVP
- established/historical/corporate companies that already have an established stack that you are not going to reinvent (because of the scale or simply because they wont even let you try) and these companies tend to know exactly what their weaknesses are and they search for way more specialized people to fill those gaps. they also look for "fullstack" devs but way more skilleld, akin to "tech gurus" that act more as lead devs/team supervisors to help out anyone that might run into trouble, so in this case you'd better have some nice work experience.
Anyways, frontend/backend/fullstack, in the end, the pay potential and employability is all about how you sell yourself and nothing more.
1. A lot many experts are totally unaware of the other side of tech.
2. Experts charge much more even if the requirement wasn't huge (if freelanced expert)
3. Communication is hard. Communicating with four experts about new systems is much more hard then communicating with four full stack devs.
Its curious how the work that full-stack developers could accomplish on the server/hosting, load balancing, database, backend, and front end, has been broken into 6 different jobs.
It's true that they have different skillsets, but you also develop software quite differently knowing how load balancing or other pieces work.
My observation has been a shortage of experienced full stack developers resulted in accepting junior developers who only work on the front or back end while their skills broaden, or deepen.
Many experienced (more than 2-5 years) developers I know have spent a few years at a time working deeply in front-end, back-end, or infrastructure solutions as it might relate to their current work.
Front-end and back-end development focus can be seen as a path to growing one's skills. A developer might grow towards the other, or broader in their existing area.
1) Built their own crawlers.
2) Using an Apache Nutch/Heritrix cluster in a colo facility.
3) Use 3rd party services like mixnode.
I'm part of a small team that works on portier, which is what one could see as open source alternative to Auth0 (it's not the same thing, and it is more inspired by Mozilla Persona, but close enough). It's a service, as we run a broker online for everyone who wants using it, and the whole concept is having self-hostable brokers that handle the login of users (via email or Openid).
But: While that broker has a proper and simple API one can use to use the service with every language, it is still so much easier to just include a library/module that does that for you. Interpreting the jwt, fetching the jwk to check the signature, packing the request to the broker properly. We currently have one for Python, node, php and ruby/sinatra. They are not all at the same level, the one for sinatra does almost all the work for you, while the the python library is more a set of helpers.
And I don't think that's something weird we're doing, look at services like stripe or superfeedr, they all have language specific libraries to make calling their web part easier.
So what I'm saying: If you run a service that targets devs you might still end up writing language-specific libraries. And I don' think there is much keeping language-agnostic services from happening, as there are a lot of them.
Edit: Though open source there is less, right. I think that's a mixture of the skills you need (having a proper server online and programming the software, not every team can both), the popularity of self-hosting in that community, and that it might cost money to run the online service.
If you are currently using a library that operates synchronously on in-memory objects and offers an idiomatic API in the language of your choice, switching to a web service may feel like a bucket of cold water because suddenly you're dealing with an async-only interface that sits behind a slow socket and requires serializing everything to a lowest common denominator API. It's a huge tradeoff that requires serious justification.
Back in 1990, there was an industry standard called CORBA that attempted to turn libraries into services:https://en.wikipedia.org/wiki/Common_Object_Request_Broker_A...
There's a reason why we're not using any CORBA-based software. (Well, the GNOME desktop was based on it for some time, but they gave up eventually.)
Here's one: Money.
A service will cost me (more) money. A library I can deploy on already-existing infrastructure. Keeping in mind that "Cloud" is 3x to 6x more expensive over running in house, this is a significant drawback.
- A clever and clean way for tracking changes and additions for hand written notes.
- Evernote allows adding hand written notes, but they go page by page, which is frustrating when notes or designs span longer lengths. Allowing a continuous stream of hand writing would be great.
- Better merge resolution. When you happen to make a change on the web (clip a web page for example) while writing notes on the iPad, I often lose notes.
Many app are stop, if issue with net connection or send a big notification about my internet connection issue. Why I have to see it? Can app not manage sync & net issue with local storage or something. I mean I am just taking a note and for taking a note, a real time internet connection is not needed., Right? it's not email app where connection is more important.
For now I settle with org-mode in terminal because I avoid the cloud.
I am a very heavy Evernote user but it has nothing like this.
* Excellent synchronization across devices
* Support for handwriting
* Web viewer
Going to a developer conference as a developer might seem like an obvious choice but going to an event with a slightly different though still adjacent topic might provide a better learning experience and allow you to get to know people from outside your usual circle of interest.
Design conferences are particularly intriguing for developers. I can highly recommend both Reasons to: (https://reasons.to) and beyond tellerrand (https://beyondtellerrand.com/). Both have a similar background and deal with design and web topics as overarching themes with talks ranging from front-end technology in general, data visualisation, to typography and art (as of lately including quite a bit of generative art).
Events like that can be very inspiring and they can provide you with insights from other subject areas that you would've never thought to have an impact on your daily work.
My favorite talk from this year was about implementing an algorithm for HDR photography purely in Microsoft Excel - https://www.youtube.com/watch?v=bkQJdaGGVM8
1. People who speculatively hold an asset have an incentive to talk it up, even misrepresenting their own beliefs about its merits and future value. Thorstein Veblen wrote a whole thing about how this happened with real estate in the U.S., where people felt immense social pressure to persuade the broader public that a particular town was great because their assets and their friends' assets were tied up in land in that town and they all wanted their property values to rise. It's annoying for people if they feel that they're getting a pitch that's ultimately inspired more by someone's (possibly undisclosed) market position than by someone's honest assessment of the situation.
2. Altcoin creators and early investors stand to become rich, possibly at other people's expense, if there is sufficient interest and enthusiasm for an altcoin, even briefly, regardless of the altcoin's level of technical or economic innovation.
3. There's a lot of disagreement about economic ideology and policy issues around cryptocurrencies, familiar examples including Bitcoin's intentionally deflationary monetary policy and Monero and Zcash's privacy. This can add an extra level of contention and disagreement in this area, sometimes in the background, and people may be upset by the particular choices or policy goals that others have adopted. (And a lot of people have diametrically opposed beliefs about whether governments should have more or less power than they do today to set monetary policy, to monitor transactions, and to prevent particular entities from receiving payments.)
4. We've seen with the DAO and the current Bitcoin forks that there's also uncertainty about governance, including a conflict between people who want to see purely code-based rules set at the outset and enforced forever, and people who want some kind of community to have a way to amend the rules. To some people, the failure of meta-consensus about governance and decisionmaking is a long-term fatal flaw in cryptocurrency communities, and a way of glossing over something really necessary.
5. Cryptocurrencies have experienced high rates of frauds, scams, and theft that suggest to some people that they can't be taken seriously as a real part of the financial system, since the risks seem unacceptably high and there aren't straightforward ways to insure against them. Most new projects don't directly change this situation.
6. We've also seen tons of projects adopting blockchains that obviously don't need them because the participants in the system already trust each other or at least already trust a common authority that they agree is allowed to adjudicate disputes. In that case, the common authority can maintain a central database, or the participants can maintain a simpler distributed database and appeal to the authority to resolve any disagreements. (Maybe there are some cases where something blockchain-like is ultimately cheaper because it simply reduces the frequency of disputes that need to be adjudicated, but in any case a lot of people adopting blockchains seem to miss the point about trust and decentralization.) So there is a skepticism that says that most often when someone used a blockchain it was probably for buzzword-compliance.
One clear thing to me was that Ethereum had no security story.
Well, it has a story for the security of the base challenge, an actually interesting story that if you have five different implementations that are evenly used, a hole in one of them won't affect the whole system (unless it reaches 50% adoption.)
However there is no security story for applications built on Ethereum. Thus the DAO hack, the ICO hacks, etc. Experience shows that you can't trust the run-of-the-mill programmer to get that kind of thing right, and you certainly can't trust bankers, traders, and fin-tech brogrammers!
There are also interesting reasons why blockchains were only developed lately. If you went to a distributed computing conference and presented a paper about a distributed system which did not improve it's ability to handle workload at all when you add more nodes, you'd get laughed out of the room.
And then there are the people who talk about "fiat currency" and who think that Bitcoin is like gold. Bitcoin is not like gold. People wanted gold 4000 years ago and they will want it 4000 years from now unless we are extinct or unless we find an asteroid which is made of solid gold. No way are people going to want Bitcoin 4000 years from now.
The reason why I would came out at skeptic is because its proponents are full of shit, political and naive to the extreme and they are against government by default. Alternatively they are cynical businessmen riding with hype.
Proponents can't distinguish different roles of money. They have never heard of basic things like: optimal currency region, connection between balance of payments and exchange rate, smurfing ... They think they have discovered something else than just new payment and transaction method.
Also partly due to the fact that the technology is being overshadowed by the fin-tech bros looking to make a quick buck, and it's reflected in the quality and quantity of crypto related articles that are being written in the first place.
There are still some good discussions, but for the most part people are sick of seeing the same crap repeated daily with no critical thought or real news to speak of.
When it's another blockchain-as-a-cloud-serverless-service, it's usuallymade by cryptographic dilettantes who don't understand what is theblockchain's function and just want to join the hype bandwagon.
To me, the key is to think of everything in your app as a component. You should be able to drop the component into more or less any context and it should 'just work'. Following the ideas in the videos will help you accomplish that on the CSS side.
CSS is a Mess - Jonathan Snooks (ex-Lead Frontend Developer Shopify)https://www.youtube.com/watch?v=fAcW-wOFYjw
CSS for Engineers - Keith J Grant (NYSE Engineer, author of CSS in Depth)https://www.youtube.com/watch?v=J-9Tn6AetYA
They have a visual guide which shows you what it looks like along with code on side.
Another suggestion, such as SMACSS is BEM (my personal favorite), as it flattens out your styling to prevent over specificity and makes everything clean and neat. (Check it out here: http://getbem.com/)
Ultimately though, what I've found reduces messes is to think of the end product before beginning. If you have the luxury of starting with a fresh codebase, think of the end product and its styling before starting- much like you would with any other set of features in any other language.
If you're walking in to legacy code, try to avoid the "one-offs". Sure, they solve the problem now, but its making a mess for future you to clean up as well as being a potential code smell. Leave your code a little better than when you came in and you'll be thanking yourself later.
Other than that a lot of my CSS cleanup happens in refactoring the layout
Google, Facebook, and Amazon (due to the connection with Washington Post) are vilified, and multiple posts reach the top each week outlining alternatives - Duckduckgo is a major one, firefox/brave are suggested browsers, and in general people on that sub talk about completely disconnecting from facebook, or minimizing use to messenger only.
I can see a pretty sizeable opportunity for platforms to come out that are truly tolerant of all speech/perspectives. I'm not criticizing, nor expressing favor towards, any of the services I've mentioned, but it seems like someone could make a solid earning in a lifestyle company aimed at servicing individuals who want privacy and uninhibited freedom of speech.
For reference, T_D is in the top 125 of subreddits by subscriber base and activity. If you exclude default subreddits, they're probably in the top 50 subs. Considering they probably have even more penetration through the amount of lurkers (like me), I wouldn't be surprised if they drove a sizeable chunk of users away from Big-Tech.
Edit (for personal reasons): I'm not on T_D because I support Trump. I go there to get a perspective of people who I don't completely understand, in order to better understand their needs/fears. Also, their memes are dank.
Name kinda sucks - i always typing duckgogo and ending up at spammy site. WTF is duckduckgo?
Can't we do a brandy shortcut or so?
Unless you are the copyright holder, I don't think it is up to you to release the code.
It's no surprise the topic makes for good HBO drama.
There's no shortcut. Just stay calm in the chaos. Focus on one thing after another, especially when it's tempting to do many things. Don't outsource core stuff early on; it's tempting when time is always short, but it often makes things worse.
Be honest, completely, brutally honest to yourself. Startups are the last place to lie to yourself. You don't have 'hope', you have plans and hypotheses.
Startups are this long march. You either die or you make it rich. If you can simply avoid dying, you will be rich.
The NYC FinTech Meetup is also usually a good place to network:
Like I said, I've definitely observed this phenomenon before. I've also observed that it's likely confirmation bias: I don't remember all the OTHER things Facebook advertises to me. The only reason that ad for the coffee machine jumps out at me is because I was just talking about it, but who knows how many times it showed up on my feed and I just glossed over it because I tend to gloss over ads?
Posts like this come up quite often, and I definitely think it's dodgy and suspicious, but ultimately, I think it's just clever marketing tactics by Facebook to determine what to advertise to you.
It's probably some combination of your IP, cookies, location, account relationships, credit cards, etc etc. There's a lot of pretty simple data they can use to make the decision to show her Ads on Facebook's Ad platform.
[edit:] This may be considered as dodgy. In Germany it is forbidden to use the lookalike audience feature of FB and companies are fined if they admit using it.
1. Amazon passed your [IP address + SKU browsed] to facebook ad platform. And facebook knows from there on.
2. Facebook snoops on your audio and its ad platform pulled SKU from amazon.
3. You have various extensions on your browser which can "read all websites data you visit" - which have sold your browse information with IP to facebook.
Third is most likely.
+ I have noticed - "somehow" my facebook learns what I watch in youtube and vice-versa. Only way this could happen is via one of my "trusted" browser extension!
Clear all cookies between browser sessions.
I assume its due to the fact your amazon has been linked to her facebook account at one point or another as you were logged in to both at some point.
I mean, we're talking basic product advertisement from the largest store in the world...
Company 1: Started by myself, partnered with a sales guy 50/50 after a few months. Company took off after the sales guy because he was able to close large contracts.
Company 2: Started with two other people I knew well (doctors) who were in the field but non-technical. I ended up leaving company after 3 years. This was in part because they couldn't put in the same amount of work (never partner unless they can contribute full time).
Company 3: Started by myself, raised money by myself.
Moral of the story: Partner with a sales guy if you have something to sell, and make sure they have a proven sales track record. If you're building a product that won't be ready for a long time, work on it alone and test the markets as soon as you can, then partner. There is no right answer, but don't partner with somebody simply because they are on the business side. It's also much easier to pitch with a sales guy. And don't partner simply because the business guy has an idea.
But by far, I find that the strongest indicator of a good partner is whether you're adding them on Facebook.
For one thing, partners that avoid you on social media are a little dodgy. Some would even see you as an adversary - this guy they negotiate against, that they're going to leave when business is over, that we're splitting equity with.
And often there's some subconscious disgust to people you're not willing to add to your friends list. The reason for this disgust often becomes clear in about 3 months. But we have years of experience with people - if something is off about them, we'll know.
The best partners to work with are the ones who you want to get closer to. The ones who match with you on an ideological level. The ones you feel that you can learn a lot from. And more importantly, the ones who you consider a real friend, or truly want to be friends with, and are willing to go to long extents to help.
If you feel the need to test this person just because they have a nice business model, I'd suggest that they've already failed the test.
The 2 business guys thing is something to be wary of. I can't think of any tech startups that had 2 business founders.
The biggest problem is that it's tough for you to judge their output initially, since there is no product to sell. If they can get customers lined up without a product, that would be a good sign.
If they can raise funding on their own, and THE MONEY IS IN THE BANK, that's a good sign.
The worst ones are those who have "connections" and will sell only when the product is fully fleshed out. They just keep asking for feature after feature while sitting there, twiddling their thumbs.
If they are cagey about paperwork or details, it's a bad sign.
It's hard. I have been burnt once already. Sales is hard. REALLY hard. If you do decide to try it out, make sure they too have targets to hit.
Ideas are cheap, tech is the hard part. Why waste 66% if your equity on two guys with an idea? If their idea is good they can hire developers or raise VC to makd their MVP.
Have been on both sides of this. In most cases i dont think the random business guy is worth hooking up with.
If they can't develop product and they can't sell, they're useless to a startup. That won't take long to suss out.
Go all out, full marriage, full honeymoon. Have meetings as necessary. Work at it. The biggest problem with business guys is failure to close- either they don't put the time in or just can't sell.
Give it three months, and either pat yourself on the back or throw in the towel. Repeat until you find a successful venture or have to get a job.
One other warning about "two business guys". They tend to turn on each other more often than they turn on the tech guy. It's often sudden and unpredictable. Make sure you have that contingency covered in your formation documents.
In general, if you have a good thing going, you cant wait for him or her to meet your friends, siblings, parents, the guy at the deli, and you wouldnt have any qualms about presenting this person to professional acquaintances, people you knew in college, family friends, even your ex.
As a non-tech sole founder I hired two developers in this mode. I called "freelancer as a test to CTO/co-founder". They both were interested in building a new web app from scratch using the stack they wanted so this allowed them to charge a discounted price.
I paid them by the hour totally trusting them on how many hours they had worked each week.
The startup ended up failing, but this arrangement was great for both parts.
If the startup had been a success, I believe the arrangement would be around the lines of some below market salary with large equity (but not co-founder level). Probably from 20% to 30% before any funding
Today, being a technical co-founder gives you an advantage. However, that advantage is really a broader pool of people and ideas that you can work with. When you get a match -- that's it -- you're now all in this together. Choose wisely, then commit strongly. Personally I'd be uncomfortable with a situation where I was getting paid and my co-founders weren't.
If it's early days, or you've just met, stress test the partnership. What sort of exits are you after? Ask some hard questions. What if we couldn't fundraise? What if we need to to layoffs? What is we get a generous, but not massive, offer in the first couple of years? Some of those questions will feel churlish when you've not even got any runs on the board (and they are), but they're essential to finding out if this is a work dynamic that will make you successful.
Really push it. You should (must) have some really uncomfortable conversations early on. You'll have them eventually, so better to know who you are together before investing too much more time.
The good thing about the above is that you can do that pretty quickly. Start with an afternoon, a weekend, a few working days. Then go from there.
If you make a deal with some small portion of equity now, you set your price too soon. Making it harder to get equal partnership. Better to explore the relationship first with a easy and fair exchange of value (work for $).
Step 1 : go cross the atlantic on a boat just the 3 of you.Step 2 : you didn't wanted to kill eachothers ? Good. Now give them all your credit card numbers and keys to your house.Step 3 : You trust them enough ? Alright you're good to go.
I think the most advantage, that my partner impress me is he is really initiative, includes (not only) use our product, find bugs, fix UI, marketing, and everything.
I'm glad to work with him, and proud of our work. We got friendships first. I think i got my answer.
How does it work in the "real world"?
You get a P.O. Box.
You leave that address, the Post Office re-rents it to someone else.
I would guess that should be your care to make all people that know that address to not send anything to it and/or change all references to it.
By the same token it is your responsibility to change all your current subscriptions/whatever updating the e-mail address to a new, valid one, the sheer moment you delete the "old" account.
I imagine there are easier ways to extract money from people. There are too many unknown unknowns here.
The fact it happens for a service as massive as Outlook is unforgiveable though.
It's 0.1KB. It's so small that any SVG version of it would actually be a larger file (seriously, I tested it with an SVG converter script online, and the SVG came back at 0.6KB).
There's no practical reason to convert it, at least not as far as file size is concerned.
It's about focusing on interesting content rather than pixel perfection.
It's about shipping on Tuesday rather than shipping on Friday.
It's about optimising the things that are important.
I like it, even if it's a big pixel-y on hi def displays, it's a reminder that done is better than perfect
My company has heavily invested in blogging  which has helped us become influential in the product space (enterprise ETL around Apache Airflow). As an engineer, every time I write a post I try to balance time vs ROI. I think it's more valuable to pump out a good post that takes 5-10 hours of effort (not counting writing the code etc) vs tons of very low effort posts when you're first getting started. Occasionally, you can find time for a high investment post like 20+ hours but this is pretty difficult and probably not worth your time at the early stages.
If 10 hours invested into writing a good post turns into thousands of page views turns into a small number of conversions, this can be very beneficial in growth.
One trick you can do is recycle ideas across blog posts, meetup talks, and conference talks.
Another thing to think about is that not every engineer enjoys investing in writing. If it's not something you enjoy, I wouldn't force yourself to do it. Some people are much better at formats like podcasts or videos (personally I'm the opposite though).
Happy to answer more specific questions if interested (email in profile). Feel free to reach out.
In the early stage, focus should be on generating money so you become self sustainable. If blogging is part of that strategy, so be it. But blogging for bloggings sake isn't probably a good spend of your time.
However, the relationship between doing something here = an equal loss somewhere else is rarely true - so if it's something you enjoy doing as something different to your normal routine then why not.
We've written a fair few blog posts in the past and always focused on keeping them high quality and is has paid off in some ways - I would say though that writing a good quality blog post easily can take 1 full days work. If you're looking to outsource it, you're doing it wrong.
This will also get you more press coverage too, which is much easier to come by when journalists know they've got a guaranteed audience for stories about your startup than if it's a completely untested idea with no existing audience.
When your startup is young, your job is to keep it alive (which usually means to get it growing). Blogging can help, but don't blog if there are other higher value things that you can do.
The plan was for that team to grow so they were also doing the following 1) Developing tutorials and videos for frequently asked questions 2) Tips & Tricks - blogs, tutorials, videos 3) Better Routing of customers to the right group (e.g. tech support). Basically a second layer of defense after the account executive. This was really important for new customers who didn't understand the correct channel to reach out to for help.4) Have scheduled public sessions (e.g. 2 hour chat sessions) where customers could get tech help, demos, etc. Typically this would involve one person from the customer success team and one from some other team with more expertise in the product(s).
On the one person team, the "manager" didn't manage any people. The managed the customer questions and site. As the team grew, there was a plan to have somebody who actually managed the team.
Good luck with it. If you do find anything or start your own, please report back.
> We are investigating reports of elevated error rates.
I guess the idea of 'think big' is just wrong. Young folks get pressured into 'making it' that they believe thinking big would solve your problems/make you great. That's what I experienced. Don't think big, focus on discovering the tiny little things - the ones broken, and fix them. That's joy enough for a Hacker.
When the patent application failed, I decided to close the business. Without the IP, the more I built the market, the more likely someone else would come in to compete, and an established manufacturer could definitely beat me on price.
I learned a lot about how difficult marketing is (I come from a mathematics and software background) and how much footwork goes into sales. I also made some mistakes in the patent process I won't make again.
It sucked to give up, but was also a relief. I wasn't betting my future on it, so it wasn't a huge hurdle to make the call. No patent == no business.
I'll probably try again some day.
When? For the past 4 years.
Why? For several reasons.
I started a company before (3 times actually).
The solo business was a slog, spending a lot of time doing things I hated to for barely enough money to feed myself, and with little outlook for growth.
The first VC-funded startup burned me out big-time. I'm not cut out for years on end of 60-plus hour weeks for a tiny chance at a large payout and a 98% chance at nothing. Especially given the opportunity cost of a senior engineer's salary.
The second startup I almost didn't do, but I was super passionate about the topic. Unfortunately, the team fell apart, but not before the stress impacted my health (permanently) - and the other things I learned from that experience informed the other major reason I'm not doing that again any time soon.
Which is that ideas are a dime a dozen, but good ones are rare, and marketing is HARD.
If I were to stumble across an idea I couldn't pass up, that would make a solid lifestyle business (no way I do the VC dance again) and that I could build in my spare time... ok, I might try again.
But starting a company and hitting it big areno longer part of my dream.
Instead I'm working on moving to a place I want to live, finding a 20-30 hour/week gig (be it contract or salaried work), and living a life that I can actually enjoy day to day, spending time with people I care about.