This survey was based on 258 developers responding from the UK. I don't recommend making sweeping generalizable claims about all developers in the world from it.
If you find the content useful there, maybe consider paying the $5/month to get access?
Sounds like you place enough value that it would be worth it to you, and you can feel good knowing you're helping contribute a small way back to the author (who gets small proceeds based on how long you read the article) and supporting one of the leading platforms for an ad-free experience to read interesting content without all the distracting popups.
Can you please prioritize stability of your SaaS offering for paying customers? Our dev team and infra gets impacted seemingly every week with github outages, and it especially seems to correlate with delivery of new features. Thanks!
It actually gets a lot better at categorization the more you use it. It has at least some primitive machine learning (possibly rules engine?). Categorize a transaction once and it usually gets it right subsequently.
I started this right after college after reading "Automatic Millionaire" that advocates for "paying yourself first" and automating your finances. Money goes into checking then automated to online savings accounts, one account per purpose (xmas, vacation, kids college, kids sports, big ticket purchase), money goes to 401k/IRA, money goes to stock account. Only bill I need to remember to pay is credit card (although minimum payment is at least made so no late fees), everything else is automated. Only decisions I make are how to rebalance things if I overspend the money left over, which stocks to invest, and periodic rebalancing to make sure things are on track to reach long-term goals. The real savings is "saving me from myself" :)
Just like the chicken and egg, it doesnt matter which comes first, code or test. The key is that both are written, ideally around the same time and part of same changeset. Refactoring posthoc for testability is tricky and often brings to the surface poor software designs in the original implementation - bad coupling, module dependencies, leaky abstractions, etc.
There are a ton of SBIR rules so you'll have to be prepared with your accounting system, timekeeping policies for employees and other legal contracting.
First, check your company's eligibility. If you're VC backed then I'm not sure your company is eligible for the SBIR program. I remember there being some proposed changes but I'm not sure they were made official or not regarding VC-funded small businesses. Also be aware that you are granting the government certain rights to the intellectual property that is generated under contract. You can still commercialize based on that IP, but the government has some rights to use of that software.
If you want a general overview of the program I think you can google for the "SBIR Coach" and he has some free online resources that give an overview of the program.
If you're planning to submit a proposal to an RFP, make sure to very carefully read all the instructions in the solicitation regarding formatting and everything.
Many government agencies participate in the SBIR program. Which agency are you considering submitting a proposal for?
Let me know if you have more specific questions. I worked in the SBIR industry for about 8 years.
I think comparing feature for feature isn't the right way to understand why Slack is a disruptive innovation.
Often it's an innovation along some other dimension - process, business model, etc. In this case it's Slack's business model and "platform" strategy. Other tools like HipChat were just that, a tool. Slack is a platform in the sense that it enables businesses and developers to leverage and extend the platform, thereby adding additional value to the platform. This leads to so-called "Network Effects" where as more apps are built on the platform, the more valuable the platform and the more likely others will want to build on that platform, etc. in a virtuous cycle.
Language is not an immutable thing and is always evolving in its use to reflect the concepts of the people using it. I think capitalizing Agile as a noun makes it a "thing" that we can refer to collectively and ultimately helps us communicate about the concepts that it entails. The unfortunate down-side is when a popular term is misused due to ignorance and misunderstanding by a large group of people - which will happen more prevalently as a word becomes popular.
As someone who has had the pleasure of receiving Scrum coaching from Jeff Sutherland, I can say that there is a HUGE difference in understanding between people who spend time to learn it (from a book or coach) and those who muddle their way through - never taking the time to learn about it more deeply and put it to practical use (the only way to truly learn is through doing).
I work at a small company and teach an internal course on the principles of Scrum to our project managers, so I have first-hand exposure here. It's amazing how really smart people who have heard the terms used for several years and even claim to have been involved in Scrum teams at past jobs still have many misconceptions about the core principles and how to practically apply them when the situation arises. There is definitely a shallow understanding amongst a good majority of developers and it's exacerbated by companies that claim to use "Agile" practices yet have only really scratched the surface. It's immediately clear that many have used "Scrum-but" and really only do standup meetings as if that will be all that is needed. Actually many people think Scrum is "that process where you hold standup meetings".
I like Scrum because it brings together not only a way to manage a project, but more importantly a way to lead a team of people! I think being a servant leader to the team and providing them the necessary resources to be at their peak effectiveness is a trait of a good leader. It's actually kind of amazing all the different ways even very smart people can get "stuck" - distracted by a less important task that is shiny and interesting, slog through hours of debugging to resolve an issue that someone else on the team could have helped them with, not communicating with other team members that they can't get their part done unless another has provided them something first. From experience, just helping people identify these blockers and get the team unstuck has been a big win.
I think tools absolutely are a big help too. I've used sticky notes on whiteboards and it's good for small teams that are co-located. It breaks down for distributed teams. We just started using JIRA and it is surprisingly good at helping us managing all of our work which would grow unwieldy using more primitive methods.
I'm not sure how I feel about the agile manifesto. I guess it has its historic place as a reaction against the poor waterfall practices of the past and paved the way for new methods to emerge. Besides that, it seems a bit dated and hasn't served a useful practical purpose for me.
1) With the overload of information, we've adapted to skim not only sentences but skip over entire sections of content because we instantly perceive them as not having valuable information. Factoring this in, I would think our reading speeds are over 1000 wpm. I got the gist of the page by skimming the first 2 paragraphs and skipping the rest as it was extraneous.
2) limiting it to 1 word at a time is counter to how most speed reading programs teach to extend the width of how many words you can read simultaneously. Some people can grok the meaning of an entire line of text without (or minimal) saccading. Their eyes just go straight down the middle of the page. It would be nice if the app helped "train" you to be able to increase your reading width without loss of comprehension. I might actually use it then.
It's going that way. Hopefully not some annoying icon featured prominently on every page, but instead a subtle browser-based recognition that the site also has a web app and puts a tiny mobile icon in the browser bar that will launch you to the app's install page.
HTML5 isn't just about the tags. It's an ecosystem of technologies that are breaking down the barriers of the browser to enable more native-like experiences over the web. Take for example how Google Maps in the browser can "access your phone's location". Think about what it's doing - there's a browser API that web developers can call that retrieves data sensed off the user's mobile device. This used to only be possible with native apps.
Also, the HTML5 ecosystem is more exciting because of the renaissance with javascript (nodeJS for server-side javascript, many JS libraries and frameworks) and the entire developer tooling that is making web development workflows much more productive than in the past.
Yes, but I think the transition is happening rather fast (not relative to our newly wired brains perception of "web time", but like in normal human time measured in decades and life experiences).
It's actually pretty amazing to see new user behavior where they install the latest version of a web browser to keep up with the jones's. This is good for browser developers as there's a demand for improved functionality and performance, and it serves to move us all forward as a web community faster (so web developers don't need to support dinosaur-era browser quirks for backwards compatibility). It seems like web technologies have achieved a "virtuous cycle" of improvement that is propelling things forward very quickly.
It seems that the line between native app and web will increasingly blur as HTML5 matures to the point it obviates whatever advantages remain with building native apps. I think this will mean a better end user experience as there will no longer be these walls between the web and mobile experience. It doesn't seem efficient for companies to have to build a website, a mobile version of the website (with responsive design), and native apps (for every platform).
I think OP should start to learn computer science and not just programming languages and frameworks to truly understand the major concepts that he's wrestling with. There are good books and online videos on object-oriented design that would probably be a good place to start.