For me, it was an e-book  that I wanted to write to teach others about React. The idea was to learn React while building an application that is more complex than a Todo Application.
So I took the first 3 months to write the initial draft - only 90 pages. I released it on Leanpub as an unfinished book, because it was painfully hard to keep going. Yet the community seemed to like it. It confirmed me being on the right track and my motivation went up again.
Since then I iterated 4 times to improve and enrich the learning experience and "released" it multiple times. I keep it updated to the recent library versions, best practices and new techniques with the help of the open source community. Now it has over 170 pages.
What helped in my case: Release early and improve/iterate based on the feedback.
-  https://www.robinwieruch.de/the-road-to-learn-react/
People who are succesful did 99 mediocre side projects before they hit the jackpot. But it still took them tons of time and energy. Very often a overlooked by-product which was developed over night and benefitted from all prior experiences will be the cash cow while the main project which took 12 months still hasn't won any users.
Most stop at some point because it's just tough, especially the mental part.
My personal examples:
Launched Selenium as an open source project in 2004.Founded Sauce Labs Inc ("Selenium in the cloud") in 2008. (Sauce makes roughly ~$25MM a year now. https://www.inc.com/profile/sauce-labs)
Launched Tapster (then called "Bitbeambot") as an open source project in 2011.Founded Tapster Robotics, Inc. in 2015. (Not disclosing revenue at the moment, but still going strong!)
To echo some other comments, I also have many other side-projects (some posted to GitHub, but even more unpublished) that never went anywhere. Success is a combination of luck, timing, ABC (Always Be Creating), stubbornness/persistence, and getting feedback from as many people as possible.
I've worked on tons of side projects before this (most unsuccessful, some with some success - busmapper.co.uk, donothingfor2minutes.com). My advice would definitely be to launch early and improve things over time.
My most successful side-project has been the one where I didn't start out by using design patterns or TDD or fancy fun new languages as we do at my full-time job.
Instead, I spewed code vomit on the virtual floor of a tiny VPS, wrote most of it via SSH, and felt shame when users started using it because holy hell if they only knew what was underneath all that.
But ... that MVP generates income. Not quit-my-job income. But it's steady, and doesn't require a lot of changes. I plan on rebuilding it soon, as I need a better code base to handle upcoming plans. However, that embarrassingly messy hodgepodge has been running for a year, making money.
I have since then managed to get some funding and have been working on it more seriously for the past 4 months (since may 2017). In two weeks I will have another closed alpha-demo that is then going to be used to produce a video for the landing page, and opened to the public if there is no big bashing from my zen target audience friends.
It does seem like a huge desert to cross. Motivation comes and goes. In the meantime I managed to kill my desire to feature creep it to death and learned a lot about the fine art of listening/ignoring the target audience requests. I know for sure that my approach for my next project is going to be completely different than my current one. But in the meantime the rent is due :)
The landing page:https://www.pixnit.com
My blog with some thoughts on the bootstrapping experience: http://www.hugodaniel.pt
For my next project, I plan to build an alternative to Disqus which respects users' privacy. I removed Disqus from my blog a while due to the 2 MB junk it loads and sends tracking data to 10+ sites. I used to receive a few comments, so I thought I would build myself an alternative to Disqus and maybe turn it into a SaaS if there's demand for such a product. Any interest for a $10/month privacy respecting Disqus alternative + an open source code base?
I expect it to take me 2 to 3 weeks to build it. As you build more projects, you end up with a lot of reusable components, so it gets easier to build out the MVP. The real challenge for developers is to get users. This is something I don't have much experience with, so let's see how it goes.
Compare career levels across companies - http://www.levels.fyi
You cannot develop your way out of a marketing problem.
There will ALWAYS be technical problems to solve but it's all irrelevant if no one is using your product. Long development time also tends to create a familiarity with your product that users likely will not have, possibly ever.
I am a huge fan of Steve Blank's How to build a startup (which is free on udacity)https://www.udacity.com/course/how-to-build-a-startup--ep245
I wanted to learn Django and wanted to start with something fairly easy. I don't really have any idea how and where to promote it, didn't get much attention in my `Show HN` thread and most subreddits remove it because of the affiliate links to amazon.
Other than that it was a fun experience and at least I can say that Django is a great framework to work with!
Start your blogging and social media ASAP, because it takes some time for SEO to kick in. Get collecting emails so you can launch to an audience. Don't leave it until after launch, you will regret it.
Our SaaS is at http://blogenhancement.com and the blog is at http://blogenhancement.com/blog/ if you want to take a look at what we've been up to.
Cheers, and good luck in your journey!
We had the interactive mind maps as JSON already however we needed to display them on the web in a nice interface so we made a react component to render the JSON to the screen.
Overall it took about a month to do the whole thing and get a working prototype, the search engine improved a lot since then though.
After the initial prototype, it generally takes another 3 to 4 months to build out a full fledged app that I can offer to the masses. It doesn't stop after that though. There is always more to develop and improve including a lot of re-factoring.
I currently have 4 SaaS products on the market and another one in the works.
The reality is that not every concept is going to get the low hanging fruit, and for many people real life gets in the way. Plus, for some people the journey of learning is just as important as launching the product.
It might be worth considering that you shouldn't stress out if it takes longer than the conventional advice might dictate.
Shameless plug, if you or anyone you know enjoys The Bachelor series then this product is for them.
Now going on two years of development (just me) and loving every minute of it. Yes, it's painfully slow at times. Finding users is really freakin' hard. But the satisfaction of people using something I made makes it all worth it.
Building a website is not the most painful part, promotion and getting traffic are the hardest, you have to be very determined. keep up the good work, don't give up.
anyone has any good advice on marketing?
Make sure you have some form of analytics from the start so you can see what pages people are going to
Nobody uses it but it was a good learning experience.
That was back in June or so. Since then, have made many many changes based on user feedback so the current iteration is more like the cumulative work of 6 months.
I think there's a fundamental flaw in the idea that you can just pay for cheaper labor- as Steve Jobs has said before the difference in a good programmer and an outstanding programmer can be 50 to 1 or 100 to 1 you can't capture that by trying to cut your cost from $100 an hour to $20 an hour.
Software inherently is one of the most scalable business models in the world the cost of manufacturing is almost zero all of the cost is in the design they should be able to make money. The mindset of being a consulting firm has to be changed.
Edit: Or maybe there are a lot of people "on the bench" or middle management is overstaffed?
This discussion might be enlightening: https://news.ycombinator.com/item?id=12458683
I continue liking this company, but now I have my own small business so I haven't applied anymore.
* What's the likely outcome for employees?
* Who was the previous owner?
* How much did it sell for?
* Are operations in specific regions likely to be shut down or sold off?
Your homepage doesn't really tell me what this is, apart from it uses Git somehow. You told us ^^there, but not on the homepage.
Is it a RAD tool? A new alternative to something like meteor? What's it got to do with Sketch plugins?
If developers are a large part of who you see as your end user, then sure, keep as is. But if they're not, I'd consider re-evaluating the use of git as your main selling point and highlight the "history tracking" aspect of the product.
or if I check in a rewrite of a paragraph and you approve the check in do I get a cut your future sales?
I am interested to collaborate. Please ping me at firstname.lastname@example.org
Favorite - Razer Barracuda (with matching soundcard), great sound, super comfortable. (wish they hadn't broken)
Runner up - Turtle Beach Ear Force PX21 (just cause it says ps3 don't mean you cant use it on PC!)
Current - Razer Kraken 7.1 Chroma (1st gen, 2nd gen is more sturdy metal) (windows software sucks, but I use GNU+Linux)
Others I've used - Logitech G35(wired and wireless versions), Creative Sound Blaster WoW Wireless, Seihnheiser.
Favorite - Yurbuds Ironman Focus Behind the ear (lost them recently, so sad)
Current - Klipsch R6i
Others - Multiple cheap skullcandy, new model Apple.
All that said, on-the-go I don't trust bluetooth so I don't do wireless, but if you do your options expand quite a bit.
One more thing to keep in mind, if you really want the best, go to a hearing aid place and get your earmold taken so you can get the perfect fit rubber exterior for whatever model you choose. Personally, I really loved my Yurbuds Ironman Behind the ears because they stayed on the best while lifting/running/yardwork etc. Most of the time when I select, besides form factor, I mostly base selection on frequency range. Which is how I ended up with the Razer Kraken 7.1 Chroma's despite how disapointed I have been with Razor the last few years.
When I was in the military the best pair I ever had was the Bose sound reduction headphones.
I launched it just about a month ago, so it is still in a semi-stealth prototype mode.
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).
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.
There's a large (huge, actually) available dataset, and lots of interesting information you can mine comparatively easily.
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.
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.
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.
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.
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 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.
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.
We would not have started the company without that deposit and I would have done something else in that case.
Anyway I think you should know who your first paying customers are going to be before you start anything. But don't take anyones word for anything. Lots of people will say "yeah I'll buy that if you make it" but not everyone will follow through.
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 :)
The product(s) being of high quality still have sales after some years.
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
- 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.
It's not exclusively crypto-related, but they dedicate substantial coverage to developments in the whole crypto/blockchain/ICO space.
They generally approach it from a finance point of view, so it's required reading if you're interested in anything more than just the technological aspects.
News in the cryptocurrency community can be extremely unreliable and designed to influence trading negatively or positively so most people stick to sources they can really trust.
Day/Swing Traders - They use Telegram channels(Whalepool, Whaleclub, Bitstash, Coinfarm) for their discussions and pick their news from subreddits(r/btc, r/bitcoin, r/bitcoinmarkets, r/Ethereum, r/ethtrader).
Developers - Slack and Telegram. Reddit and Twitter for their news
Subreddits for daily traders: /r/bitcoinmarkets, /r/ethtrader
Brb, building HN for crypto.
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.
But, as to where skepticism comes from -- these so-called "coins" have been conjured out of thin air, are not backed up by anything or anyone, and have no intrinsic value. And yet somehow they have become worth over $100 billion.
Perhaps one or more cryptocurrencies will indeed emerge as a long-term store of value. But I think that skepticism is a quite natural reaction.
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.
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.
And the dotcom bubble was better, because at least the stocks had liquidity and were traded on established stock markets...
Missing on bitcoin is equal on missing on the power ball for me...
Basically I don't see anything in the crypto world yet, one day maybe when the technology is mature and real shares are traded on real stock exchanges, but right now, no thanks!
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.
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.
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?
1) Built their own crawlers.
2) Using an Apache Nutch/Heritrix cluster in a colo facility.
3) Use 3rd party services like mixnode.
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.
2) Combine that with offline note taking that auto-syncs when you have a network connection again (even if the note-taking app is backgrounded on your phone), and you'd have a winner. Give me that and I wouldn't even care about support for any formats other than plain text.
3) The ability to organize notes into folders and subfolders with no limit to levels of nesting.
OK, yeah, I really just want an auto-syncing Git client on my phone.
- 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.
* Excellent synchronization across devices
* Support for handwriting
* Web viewer
I am a very heavy Evernote user but it has nothing like this.
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
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.
> We are investigating reports of elevated error rates.
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'.
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.
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.
- 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.
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.
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.