I have got a few small projects each with 2-3 servers running at a time. Elastic Beanstalk manages load balancers with auto-scaling.
The combination of "medical device" and "touch-based user interface" started me twitching. Some things to bear in mind are (1) will the interface work if the users are wearing rubber gloves? (2) there could be a problem with an infectious agent transferring from a patient to a doctor's gloves to the screen then to another doctor and another patient.
Call up TI and Freescale, let them know what you're up to, and they'll come demo/loan a few products. Talk to their engineers about your product at a high level so they can immediately drill in on a few options, then talk about hard requirements and even personal preferences/interests and they'll be happy to make recommendations on hardware, OS, language. The naming schemes and jargon can get confusing and features seem to overlap, so make sure to ask lots of questions.
Oftentimes the CPU will determine your OS; some will be more stable and have more complete drivers on Windows, some on Linux, some on specialty OSes. Of course you could take the Linux Kernel and tune it yourself, but unless you really know what you're doing that's not going to be the easiest route. Oftentimes you'll come across sites/videos showing how to get unsupported OS A to work on CPU B and get excited. Ignore those, as what the video doesn't show is all the things that still don't work, and that rabbit hole goes deep.
In general for your first project try to avoid straying too far from the beaten path and the recommendations you get from your vendor.
Sure the choice of CPU architecture, OS, GUI Widgets etc will/should involve you but hardware choice is determined by user requirement, gui, reliability (watchdog timers, failure modes), power requirements, BOM Costs/long term availability, IP Ratings, enclosures, emi, electrical safety etc and is a totally different discipline which you need an EE and can seriously backfire and not get approval if not done correct.
Saying all that working as a programmer in a hardware business will teach you a lot of the above and give you a bigger influence in future projects.
* Android, when the product offers a host of mainstream computing features. I think the rationale for going with Android is: "The user already knows how to use it."
* Linux, when the product is cheaper, and has a more bare bones or restricted function set. I don't know for sure, but I think that a Linux build can be more stripped down. Little boards like Raspberry Pi and BeagleBone abound, and if nothing else, you can create a nice proof-of-concept with one of those. I've actually done this, writing my code in Python, with the expectation that the "real" programmers would turn it into something else.
I'm not in the skill areas that actually develop this stuff, so I don't know any lower level details. My job tends to be supplying the theory of operation for the actual measurement.
Both systems use SOM's (system on a module) that are typically sold with the software tools to get you started, such as a working demo OS. It is rare to see real-time stuff done on the main computer. Since you're usually talking to some sort of device hardware anyway, it's usually more convenient to put the real-time stuff on a separate microcontroller, that's got little or no interrupt overhead to deal with.
Class A basically means follow common sense, so as long as document your architecture/design, use source control and test critical parts of the code you should be right to use whichever Android development framework you want.
These are not so common anymore. Most devices use existing OS platforms depending on the task. - time/resource critical? real time OSes - GUI/multimedia/telephony? Android - a platform for you app? Linux
Dev tools are very dependent on the hardware platform. C is common, as is C++. This is also very vendor specific. Intellectual Property add-on's for different micro's, etc.
You really should consult an expert to get guidance - you can probably do the work yourself, but making the right initial hardware choices matching the requirements will help get everything else right afterwards. Once you have hardware chosen, the rest will fall into place.
I work at a research and design firm, our projects are making custom hardware for people who don't have the expertise or time. Our most frequent customers? "We got this started and now ..." Save yourself the headache of getting half way into the project and discovering a problem you can't solve, then need to hire a consultant to fix it, which will entail redoing and eliminating features because the initial decisions won't support the desired outcome. Make a consultation, and get set on the right path from the start.
You can potentially go with bare microprocessors and something like http://femtoos.org/ to just small ARM devices with windows. You can do everything on one chip, or split the device drivers onto separate chips and drive them over I2C where specific timing is crucial.
There are many options - I'd start with listing exactly what you need to support (display, io, inputs, timing, single/multi chip, what timing / other guarantees, hardware watchdogs, failsafe states, etc.) and then choose hardware/software based on that.
If you want to produce many devices, I'd stay away from consumer devices like RPi. Simply because you may get stuck with a supply shortage. You can pretty much always order 1k of popular chips, even if it's a shipment from Asia. You may not be able to do the same for a popular RPi model. Also some RPis will get phased out / discontinued at some point and for a medical device you may need to recertify the new model before release.
Currently, we're running Linux with Qt 4 on PowerPC.
We're moving to a newer CPU (i.MX6 quad core). Freescale announced that they would continue manufacturing and supporting it for 15 years and it comes in industrial grade and consumer grade packaging depending on your needs.
We're moving away from Qt for the GUI. HTML5 is the way of the future. ;)
For people who are starting out, I'd recommend using Yocto. It's a build/development environment for embedded Linux. Look it up.
Edit:By they way, if it's not real-time critical, there's nothing stopping you from using any programming language you like except how difficult they can be to cross-compile.
For hard real-time stuff you need a dedicated rt system and you'll have to use C, C++ or maybe Rust.
For soft real-time stuff you can get away with RT-patched Linux. Any language with GC is generally bad with the exception of Erlang, Go and Nim; where the GC is optimised for low latency rather than bulk through-put.
Depending on your safety and realtime requirements you might be very restricted on component choice as well as coding style. E.g. for a deterministic system no heap allocations might be allowed. I guess that should be the case for most medial devices.
However your project sounds more like an embedded device in the sense of "user can't modify it", but it is still running some PC/Smartphone like applications. For that kind of stuff Android and Linux are often seen (in order from most-consumer like to most realtime capable). You get the benefit of being able to reuse standard drivers, frameworks and applications but being able to guarantee that it will always work is basically impossible.
Many devices therefore also use a multi-cpu architecture, where the criticial stuff is running on a microcontroller with RTOS and the fancy UI is running on a speedier SOC with a normal OS.
QNX and GreenHills Integrity are somewhere in the middle, by providing a realtime OS which still incorporates some consumer features and are often chosen if a realtime device should directly draw UI.
You should checkout the detailed requirements for your projects and what would be possible and accepted. I guess medical has some quite strong regulations for certifications. And I'm sure using normal consumer chips (no extended temperature range, no certificated manufacturing process, ...) will always be not possible.
If you're looking at building an interface, are you considering web-based?
Keen to hear your thoughts.
A great deal of embedded software is still done in C/C++. (Embedded is not a good environment for dynamic languages.)
PCAP touchscreen worked well with double-gloved fingers and there are touch controllers that will reject a stray water droplet on the screen.
I'm not sure about the OS considerations for medical device use, but for linux you might consider the yocto project, which is designed for this kind of stripped down deployment. It will limit the number of moving parts you have to validate. If you're less devoted to the open source route, check out QT's boot-to-qt offering. QT ui's are common in this field and I believe there are supported boards at a range of price points.
You wouldn't want to hitch your design to Rasperry Pi or Beaglebone or such because of the short support lifetime of individual models and components. Part of what you pay for with the industrial vendors is a commitment to supply the system for 5-10 years.
If any of this is helpful, drop a note using the email in my profile.
My company uses VxWorks, MQX, Android, Windows CE and Linux. We're dropping VxWorks because it's costly and cumbersome. MQX is being replaced by whatever Freescale/NXP is pushing now, we put a lot of resources into the older version of MQX and aren't following them into their new incarnation. We use Android for special devices, but it seems to take a good amount of work to put it on custom hardware.
The OS that makes the most sense for embedded work nine times out of ten is Linux. It's widely used, documented enough, and has the most vendor support.
A good setup? You can get an AM335x EVM with an LCD, which is the same processor as a Rasberry Pi. I believe i.MX6 has an EVM with an LCD as well. Bottom line, you should talk to vendors, to see what they have to offer. Since it sounds like you have limited experience in this area, working with a vendor that will give you support is probably the most important thing.
Your developer tools are entirely dependent on your OS and chip. Ultimately, doing embedded work you're most likely going to use C/C++, but if you're on Linux or any modern operating system, then you have the ability to use a scripting language.
Other stuff is separate.
Do you need to integrate a lot of sensors or have a lot of IO?
So much depends on the stage of the development process you're in, what the goal is of this project (i.e., internal testing, research use only, human use), when you're going under design control, and what market/regulatory framework you're working under (FDA, CE, CFDA, etc.).
Your requirements documents are a good guide here. I personally separate them as Engineering Requirements Document (ERD), Software Requirements Document (SRD), and Market Requirements Document (MRD); your questions would touch all of these.
You've hinted that you are wanting a display and also wanting to do calculations; as others have suggested, good practice would be to separate this functionality. Your ERD/MRD should specify a minimum duration for projected parts availability. Dealing with part variations is a pain, but having to replace an end-of-life'd (EOL'd) part is worse. For your own personal sanity, you probably shouldn't be looking at consumer-level parts and instead look for more industrial-style parts (a weak example might be to use a BeagleCore instead of an RPi for an internal project). You'll need to be mindful of your environmental requirements too, if for example your design called for a sealed enclosure that could greatly impact the parts you could include in your design due to thermal management. Even when using consumer level stuff, say USB, you should look for the industrial/ruggedized versions (e.g., that will have retaining screws).
Touchscreens for medical devices are, in my experience, a mixed bag depending on the application. If you're using a good design, they can be easier to keep clean and disinfected vs. buttons. On the other hand, depending on the touch technology you use and the type of information you're displaying, the display may not look great (i.e., a 2D plot can look fine on a resistive touch panel, but video may look foggy). Depending on what your users are doing, you could have smudges of some sort of fluid (or boogers, or giblets) obscuring info on the display. Also, I think users expect a modern multitouch experience now and I personally haven't been thrilled with that style of interface on anything other than capacitive displays.
If you're using a contract manufacturer (CM), they are a great resource. You'll be dealing with them during design for manufacture (DFM), but it's a good idea to engage them early so that you can design for DFM (if that makes sense). I don't know what your expected volumes will be, but on things other than durable goods (like scalpels), "high volume" medical quantities are considered "low volume" for other areas and this will greatly influence your design. I also found it frustrating because you're limited to suppliers/distributors/CMs/whatever that will be satisfied with the lower volumes.
Handwavy answers are that your safety-critical stuff is going to be hard real-time and running an OS developed under an appropriate quality system (QMS) like vxWorks, Integrity, QNX, etc. I don't have experience with it, but there is also FreeRTOS with an SIL (safety integrity level) 3 SafeRTOS option that could be an interesting contender. The software you develop will also need to be developed under a QMS as a broader part of your software development lifecycle (SLDC) and greater product lifecycle management (PLM). There are guidelines to use software of unknown pedigree (SOUP) by bringing it under your QMS, but this can be undesirable depending on circumstances. Most commonly the software is developed under C or C++ with an appropriate coding, review, and testing standard; for a greenfield project I think that considering Ada/SPARK or Java (with the appropriate compiler/VM) could be smart.
For things outside of the safety-critical areas, you have greater options, and it might be largely sufficient to develop under a QMS. You're going to need to be very mindful of software licenses to make sure that they are aligned with your project's requirements. If you're set on Linux then Yocto would be worth exploring, but NetBSD would be my first consideration due to licensing. For your GUI, FLTK could be worth considering if it met your requirements. Even if your product is Class A, it's maybe helpful to keep the more stringent requirements for Class B/C products in mind, so that you can (when and if it makes sense) develop expertise and institutional knowledge for Class B/C products later on.
I'd recommend the Stanford Biodesign textbook as a one resource to help get up to speed: http://www.amazon.com/Biodesign-Process-Innovating-Medical-T...
Finally, considering your questions and I say this in the kindest intentions, you should be participating in the process but not be signing the decisions. If your company doesn't have the expertise in house, it would be worthwhile to either bring someone on board or engage a consultant.
First they had Python scripts to do things on various machines. (It actually sounds a lot like Ansible: lots of little scripts that all ran over ssh.) But because of high configurability, these didn't always work right.
So they wrote a bunch of tests, e.g. ClusterExistsInMachineDatabase, DNSTestHasBeenAssignedMachines, so they could find out what wasn't right when a new machine had been provisioned.
Then they realized that fixing the tests could usually be automated, so they wrote code for each test, to correct the issue if it was failing.
It seems like they sort of backed into a declarative idempotent configuration management solution like Chef or Puppet, where you say what you want the machine to look like, and the config management is responsible for getting you there.
As I think you are feeling, in config management, the redundancy of tests and automation code is a bit more ... redundant ... than with automated tests for development.
I think monitoring/alerting is another kind of test: Is the database up? Is the web site responding?
Another good story from that book is how one internal database never went down, so teams became lax about designing systems that would still work without that component. So Google decided they'd just take the database down for a bit. :-) It sounds a bit like their version of Chaos Monkey.
I'm not sure what Chaos Monkey is, but I come from an operations background, where I moved to a devops role, and automating the infrastructure builds. Testing is essential. There is no need to differentiate best practices if you're coding for the application or the infrastructure.
As you said, checking each state of the deployment should be done, I'll do pre-checks to make sure the filesystems have the needed space for the MW component, etc. I'll check each phase, and break down the phases via functions much like a developer would for application development. This helps keep my code reusable, and easy to read for other admins. It's much easier to rerun/correct one function that fails on a deployment than have to go through the entire setup again.
I'd write the test in whatever language is doing the deploy, as I test while it's deploying.
From there, it's good to have some type of audit you can run against your infrastructure, to check versions, mount points, and changes. It can be a mess when someone updates one server, but the rest are slightly different. You'd be surprised how often this happens and eventually development environment looks different than prod, and people are wondering why the applications behaving differently.
I can go into more detail later on, but hope that gives you a feel for it!
BTW, I'm at a large enterprise so these deployments and installs are on an enterprise scale, which makes it worth getting it right in the automation piece, as the person running it isn't always an expert on the automation, or the infrastructure itself. Get it right the first time or log what broke will save a lot of head aches later on.
Edit: WSJ Review: Talk to 10 money experts and youre likely to hear 10 recommendations for Burton Malkiels classic investing book.
Get real- you're a beginner reading investopedia. Active funds employ hundreds or thousands of people who work more than full-time to support an operation of systematically studying investment opportunities and exploiting inside information to beat the market, and even they don't beat the market.
Put your money in a diversified portfolio of index funds and leave it alone. Making targeted trades costs money and will do no better than index funds anyway.
Back when I first started to ask questions about investing my 401k money and diversifying the stock I was getting as an employee at Sun I took a Forbes Stock Market study at home course, big 3 ring binder, a dozen cassette tapes. It was all about reading balance sheets, understanding metrics like price/earnings ratios versus price/income, margins vs profit vs growth. I've spent a fair amount of time "fake" investing, basically doing the research, pretending I had $5,000 to invest, and then investing it in the companies I imagined would be good investments, and tracking that over the course of a year to see how that $5,000 did relative to savings accounts or alternate strategies.
Briefly I looked at trading when "everyone was doing it" back in the dot-com days (that was quite a bull market). And I was struck by how much it felt exactly like playing craps in a casino. For me, I found that for a lot more work I wasn't getting any better returns than simply investing long on quality stocks and spending the time doing other things.
I will tell you that like most complex systems, the more you learn the more you realize what you don't know. And it doesn't help that things change, sometimes in major ways, in response to various events. It isn't something you can learn and then be done with sadly.
Stock market investing reminds me of that insurance commercial with the fishing pole. "you gotta be quicker than that..."
If you want a better investment spend it on educating yourself... or something where you can have inside advantage like your own company.
I have read both and you can safely skip most chapters. I can summarize for you, that based on your description in this post, you are what Ben Graham calls a Defensive Investor, as you want to preserve capital without being able to make significant time or resources towards exploring companies in-depth.
The modern way to be a Defensive Investor is to invest 50-50 in a stock and bond ETF/index fund, such as VTI and BND. It provides broad, safe exposure that mimics how you would have done it in Graham's day. If in the future you find wanting to put the time into your investments, that is when I would consider becoming an Enterprising Investor, at which point you should read that chapter in II, and read Margin of Safety.
Peter Lynch ran Fidelity's Magellan fund from 1977 to 1990. He avergaed a return of 29.2%, increasing the value of the fund from $18M in 1977 to $14B in 1990.
His philosophy is to invest in what you know, and that the market misses things that everyday people can notice just from going about their life. I think his advice worked a little better before the age of the internet, but it's still a very solid and easy to read book.
Ignoring anything technical, there are two extremely strong things going against the markets:
1. The fact that the boomers will be drawing down on their investments as they retire and begin to spend them.
2. The sentiment that is growing against our corporatist structure that has propped earnings up (ie the jobless recovery). Whether it's Bernie or Trump you support, it doesn't matter -- well over half the country is voting against policies that have made the stock market so successful at the expense of the American middle class
My point being, market knowledge is always important to have, but I'd advise against putting all of your time into it. It's going to be stagnant for a generation. IMHO you are better off building a real business with your time. Get ahead of the game and see where the future is headed -- the trend is your friend.
Playing the stock market is, at its core, gambling, and any good gambling book will devote a large portion of itself to explaining the basic principle of money management: Of knowing when to cut your losses and how to prevent yourself from going on a huge tilt.
If you learn more about how confidence scams work you can better avoid pump and dump schemes, smooth talking investment "advice" people, and will be more wise about opportunities too good to be true.
Most of all you need to know how these securities are packaged, what the motivation of the players behind the scenes are, and how the market works internally. Be aware of the sharks in the water and what sorts of investments are being manipulated by things like high-frequency trading.
They say the final lesson is to be prepared to set fire to $10,000 in cash because no matter how good you are as an investor there will come a day where that much or more goes up in smoke based on market movements. If you can handle that, psychologically, you'll be fine. If that thought really freaks you out, better hold on to something more conservative.
I really recommend this book even if you're not interested in Finance as a general guide for thinking about stochastic processes in a practical manner. Nearly all "basic" business/web metrics can be understood best if you understand how to correctly model financial instruments. Personally, I think the basics of quantitative finance are just as relevant to Data Science as machine learning is.
I've mainly done asset allocation. That means, looking between markets and moving assets accordingly. More an interest in themes than individual companies (though themes between companies often appear).
An excellent blog for this style, generally called 'macro', is http://macro-man.blogspot.com though the financial market slang can be a bit much at first. It is funny and fresh.
Don't read The Intelligent Investor, it will just put you to sleep. Realistically, you shouldn't be picking stocks on your own. You should just be putting money into ETFs that track the market and can help you diversify your holdings cheaply.
Look up a few of the key terms in investopedia like stock, bond, etf, etc. Then, either create your own ETF portfolio via an online brokerage account, or go with a robo advisor like Betterment.
To me I think about "investing" as trying to guarantee a return over the long haul. All the smart evidence points to taking a strategy that links you to index funds. This is what I ended up doing in terms of carving up my investments https://www.bogleheads.org/wiki/Three-fund_portfolio
When I started this though what I actually, of course, wanted to know more about was the sexier, potentially much higher return end of "picking stocks". This is still sexy to me, and I still get inclinations to pick stocks every now and again, particularly in the tech sector where I feel like I have an edge. But as I've done dummy investments in the past, the market has bitten me in lots of unexpected ways. General market downturns, edgy sentiment around quarterly earnings, bad product releases etc. etc. So now I call this what it is: high stakes gambling. I do play, but with money I'm ok losing. The kids college fund goes uses the three fund strategy described above making heavy use of index linked funds.
Since my dad wasn't the richest investor in the world, he wasn't the best so I started googling and quickly came across Warren Buffett. Not only is he the best (personal opinion), he also had a strategy that resonated with me. I had read basic books on technical traders, position traders, day traders and none of that made sense to me since they often neglects the underlying business. (I also didn't find traders close to the top of forbes' list.)
Once I found something that made sense, I pretty much watched every video online or tried to read every book he recommended. Luckily Warren Buffett loves teaching so there is plenty online you can find. The intelligent investor is definitely a must read. So is "security analysis", "common stocks uncommon profits" and a bunch of others. Here  you can find a list of "Buffett approved" books in case you run out.
I've recently been trying to learn more about investing and this book has been right on the money.
Basically, the advice is don't buy individual stocks, you can't pick them and outperform the market consistently. Instead, get an index fund or ETF that tracks the whole market, like https://personal.vanguard.com/us/funds/snapshot?FundId=0085&.... Vanguard is the best for index funds as they have the cheapest expense ratios.
If you want to learn more about the basics of economics, which are important as well, I've enjoyed this lighthearted youtube series - https://www.youtube.com/playlist?list=PL8dPuuaLjXtPNZwz5_o_5...
Another similar book is How To Read the Financial Pages. Again, probably a little dated, but I don't think much of the terminology has changed.
I would still recommend index funds for the best returns, but if you want to follow the financial news it helps to understand the lingo.
Do not enter the market, right after you finish a few courses, you will just be chewed up and spit out, and find a book called "A Complete guide to Day Trading" by "Markus Heitkoetter" it is plain and simple with lots of examples, and put "the Intelligent Investor" away for six months at least, that is a good book but is not for now.
I Started three years back when i was in engineering final year, and went on to get the certification as a derivatives and equity trader from the regulatory body.
If your interest is more the short-term movements, and less investing based on price and intrinsic value, then I'd suggest branching into economics and psychology. The Little Book of Behavioral Investing (James Montier) is excellent.
I think the best way to translate what you're reading to a practical application is a paper portfolio. I wouldn't recommend single-stock selection for your $ portfolio, but researching and following stocks that you pick will make you more aware of the market. As with learning anything, document your decisions (what, when, why) and use that as a feedback loop to improve.
While I agree that you won't ever beat the market by making smart trades, this book will teach you the discipline needed to keep from losing money or being lured into stocks and index funds by Wall Street bullshit.
I don't think accounting basics will help you much in terms of beating the markt. But they may help you not to be the one who funds other people's outperformance by making stupid mistakes.
Learn to read a balance sheet, an income statement and a cash flow statement. You'll easily find good enough sources for that by googling these terms.
So...I think it's important to consider fundamental value. A diversified low cost US fund makes sense. I've also learned about bonds, I think medium grade US corporate is a good trade off, when it comes to bond funds you want fixed maturity date 'bullets'. Municipal bonds are good as well. Yada yada, AAPL.
I went to watch stock ticker channels on PBS at homes and subscribe to Investor's Business Daily.
From there, I spoke with my parent's financial advisor and was able to make some small purchases to invest some of my family's real money.
The #1 takeaway from the book is "Before you buy the stock, give an elevator speech with facts(data-driven) and reasons as to why this stock is going to be a good buy."
Turns out a lot of my investments don't stand this test!
Things to note:This is going to be hard work. It will take time (years for most). Take notes on everything you think and do (keep a trading journal).
You will loose money at first (consider it your "tuition").
Don't put too much weight on the publication date of a resource. Certainly, some specifics of market implementation have changed over the years, but as a whole, human nature (fear and greed) is the same now as it was when the first humans decided to build financial markets.
I know you didn't mention books as a preferred learning source, but, IMO they contain the most condensed stores of knowledge by the most reputable people (read: retired and/or independent) on this subject. Here's my list of recommendations:
High Probability Trading by Marcel Link
How Technical Analysis Works by Bruce Kamich
How to Buy by Justin and Robert Mamis (out of print; worth every penny)
When to Sell by Justin and Robert Mamis
Trading in the Zone by Mark Douglas (don't underestimate the importance of getting your psyche under control!)
Japanese Candlestick Charting Techniques by Steve NisonMarket Wizards by Jack Schwager (these are well worth reading)
And of course, the timeless classic, Reminiscences of a Stock Operator by Edwin Lefevre
Stock picking advice and understanding the economy:
I really recommend reading all of Warren Buffett's letters to shareholders which can be found on the Berkshire Hathaway website. They are written in a down-to-earth style and offer a panoramic view of investing, from accounting issues to competitive advantages to macroeconomics. You can also see Warren's investing style evolve and him deal with various issues throughout history, from high inflation to the dot-com boom. Warren boils down many issues into easily remembered sayings ("Be greedy when others are fearful and fearful when others are greedy", though the sayings themselves are probably as old as the stock market itself).
Find investments that have moats is one of Warren's guiding rules, i.e. business advantages that are hard to replicate.
Learn about accounting. You don't have to learn everything, but you should know about the things that will affect your valuation of an investment. Pension contributions, stock-option accounting, etc. Come up with your own metrics to compare companies in a sector to find out who is the most efficient etc.
You will have to find an edge, something that most other people don't know, otherwise you'll just follow the crowd. Things that aren't in fashion are great places to find bargains.
Understand how a discounted cash flow (DCF) calculation works. The important part in a DCF from the point of an investor is to look at how sensitive the results are with regard to changes in the input variables (because the risk-free interest rate and size/timing of future cash flows isn't known in advance).
Understand the effect of interest rates on asset prices (see DCF calculation).
Understand the debt cycle. We are at an interesting point in time, coming ever closer to our debt-carrying capacity.
Here is a nice video by Ray Dalio on this topic:
Some economists probably disagree with some things said there, but i think the gist of it is spot on.
I get asked this question a lot and usually recommend http://www.realvisiontv.com these days, particularly if you like videos.
Some variable quality, but some really excellent, unique viewpoints from value investors and macro managers there.
I would also recommend the Market Wizards series by Schwager and Inside the House of Money/the Invisible Hands by the Drobnys.
What's your end goal here? Do you just want to be able to make some good personal investment choices, or are you trying to be a day trader or algorithmic investor? The materials will be different depending on your intended path.
In any case, I definitely wouldn't pay for a class. There are more than enough free materials out there like this MOOC from Stanford GSB: http://online.stanford.edu/Stocks_and_Bonds_Fall_2014
This book is too advanced for beginner level. As a beginner, you most probably will not like this book and reading it might turn you off investing and stock market (too complex).
The type of books you want are the ones that cover basics and are easy to read. Instead of considering books recommended by others, I will suggest going to a physical book store (library is another option), pick up any investing book on the shelf, read for 15-20 minutes. If you like what you are reading or book fascinates you and you want to continue reading the book, buy (check out) the book and take it home.
If you are a visual learner, I heard Khan Academy videos are good. Also, consider reading biographies of famous investors and financiers and other story-telling type of investing related books. As I am not visual learner, I can't make any specific recommendations.
If you prefer numbers, I will suggest reading "Millionaire Next Door", "A Random Walk Down Wall Street", and "What Works on Wall Street". The first one is not per se investing book but more of an "encouragement" book that will help you continue learning about saving and investing.
> What's your story?
I learnt stock market as "substitute" for gambling. When I first started out working professionally, some newbies (like me) at work will go out to casinos or have booze and gambling Thursday nights (alternate Friday off from work). A few of these people were hardcore gamblers: studying and learning tips and tricks of blackjack, poker etc. Monday lunch at work cafeteria used to be "whining" session, how we lost so much money and odds are against us, etc.
During one such whining session, an older member at work mentioned that on his Friday off, he goes to library to read Wall Street Journal, Value Line to research stocks and check value of his stocks like checking lottery numbers in newspaper (pre-Internet days). He got his "gambling" adrenaline through stock market and how odds of winning are much better than going to casino. This was the start of my interest in stock market and learning more about trading and investing and saving. I went to library on my Friday off to read and check out any investing and trading book on the shelf. I most probably read 30+ different books in a few months period at the start. Investing and trading is the only hobby that has kept me interested over the years.
One is economics. This is a social science, like psychology, and deals with human beings, and why they act the way they do: why prices go up and down, the effect of regulation and policy, supply and demand, etc. Economics is the bedrock underlying any market because ultimately, markets are made up of people. It's sort of like how math underlies all of programming -- you don't often use it directly, but it's the intellectual foundation of all market behavior.
To learn economics, get a basic micro textbook or listen to Russ Roberts' EconTalk. It's an outstanding scholarly podcast once/week with a huge range of topics including environmental regulation, financial market behavior, food and cuisine, and the effect of law on public welfare.
The second major discipline is finance. In a nutshell, finance is all about trading flows of money, and how that's priced: if you promise to pay me tomorrow, how much should I pay you today? What is a 10% interest in a company worth? Part of finance is "corporate finance", which is "I have a company, how should I fund it" and the other part is "financial economics", which deals with markets for stocks/derivatives/options etc. and how they're priced and traded. Finance is built on economics, because the whole reason financial markets exist is to facilitate the reorganization of money/capital to better align with peoples' preferences: saving vs. spending, borrowing vs. investing, etc.
The third major discipline is business management/analysis. You'll learn this if you work anywhere for a while: how companies operate, why people are hired/fired, etc.
Mostly, just take it in a little at a time, be curious, and pay attention to the markets. Read the news. For instance, there's a lot of discussion about what the Fed will do, raise vs. lower rates. Why does this matter? How will it affect output (how much is produced), securities prices, and firms decision to invest (build stuff) vs hold cash? What will the effect on the housing market be? Will mortgage rates go up or down? Try to fit this into a conceptual model of how the world works, and refine it over time.
EDIT: Accounting, especially tax, is also important. Accounting is the basic language of business. If you want to understand the words people on TV/news are using, like "non-GAAP" or "gross margin" or "restatement", learn a bit of accounting.
For past one year, I have been very actively listening to financial podcasts, reading investopedia, taking classes on Coursera (I avoided Udemy so as not to pay for courses). After gleaning through various resources, I settled on the following:
Podcasts: Money Tree Investing: http://moneytreepodcast.com/ We Study Billionaires - The Investors Podcast: https://www.theinvestorspodcast.com/
I listened to other podcasts and finally settled on these two. I particularly like  for the in depth analysis on markets from each guests perspective/expertise.
Classes: Understanding Financial Markets: https://www.coursera.org/learn/understanding-financial-marke... Introduction to Finance: https://www.coursera.org/specializations/valuation-investmen...
I took only one course in , couple of years back and it was very helpful.
Keeping in mind that you are a beginner.
I do not invest money in stocks. As @brianpgordon mentioned below, it is very hard to beat the market, especially for a beginner. I only put money in ETF's and low cost index funds. But listening and or reading above resources keeps me educated about this field.
Personal Opinion: "The Intelligent Investor" is very dense and is not for casual investor. Read it only if you are serious about this subject.
EDIT: Edited too many general statements.
If you're interested in learning about the stock market, it's also helpful to get a good primer on financial accounting. You don't have to be good enough to actually do a public company's financial statements, but it's helpful to have enough of an understanding that you can look at a company's quarterly report, compare it to past periods and get a good sense of how things are going.
I can't think of an accounting primer that is good for this, but I studied accounting in University so I may be biased. So, if I were you, I'd:
- pick five or six public companies you are interested in.
- read their annual reports.
- Google terms you don't understand.
I have read many books since then, but none have had the uniqueness or simplicity as his method has.
It all comes down to who is going to buy and who is going to sell and for what reasons, -- Ray Dalio
Determine whether an investment opportunity is a Yes, No, or Too Hard: If you do not understand it after brief studyits Too Hard. If you do not love it shortly after that, it is a No. -- Warren Buffet, paraphrased
"The market is like a large movie theatre with a small door - N. N. Taleb
For information to input into that way of thinking, I got in the habit of reading primary sources (Fed PDFs, company announcements, etc.) as much as possible. At the time I had a subscription to a service that aggregated primary sources in the sectors that interested you. That service has pivoted a few times since then and is now useless for gaining a real information advantage.
Edit: yes, commuted is what I meant. :) Leaving for posterity.
0 - https://andrewhallam.com/
1 - http://canadiancouchpotato.com/
This will give you an idea and maybe whet your appetite about how markets and trading actually work, and all the reasons people use markets. From there you can work towards learning more about actually developing trading strategies more complex than buy and hold.
The best actionable advice I heard from somebody making a living from it, paraphrasing:
"Imagine you are a mouse. Investing is to learn how to steal the cheese without being caught."
Motley Fool Investment Guide is where I started. I've subscribe to their Stock Advisor newsletter for nearly a decade and have picked from their recommendations in that newsletter. Basically i've invested money in one of their picks once per month with the expectation to hold that investment for 10+ years. That portfolio has gained an average of 25% PER year and I've never researched a stock.
The Bogleheads' Guide to Investing
A Random Walk Down Wall Street
You will know 99.9% of what you need to know.
Howard Marks letters at Oaktree
Jeremy Granthams Letters at GMO
Seth Klarman's Margin of Safety
Investor letters of good hedge fund managers (einhorn, dalio, singer, etc)
Generating alpha is very, very hard; If you want to maximize your financial wealth it might be better to focus on earning more money (for example by acquiring in-demand skills), living frugally and be content with market-returns (which have been fantastic over the last 200 years).
What is true for most skills is true for investing: instead of reading about it, start doing it right from the start: Pick a company (maybe smallish <$250m market capitalization, so the complexity is less overwhelming) and learn as much about that firm, its competitors and the market it operates in as you possibly can. This process can take weeks of full-time work for a single firm.
At the end of the investment process you have one task and one task only: have an opinion on whether the company is selling for less than it is worth.
You don't actually have to commit capital, just start a watchlist (a couple of dry-runs will be a good learning experience!)
Be aware of the fact that investing requires a lot of discipline: thorough analysis is tough and time-consuming. Also, investing is contrarian by default: you don't outperform the market by doing what the market does (D'oh!), you have to think and act independently.
Investing can be an emotional roller-coaster (e.g. it is tough to admit that your judgement was wrong and cut your losses).
Investing is more art than science, uncertainty about the future and facts you cannot know are lurking everywhere, you'll have to develop your own principles (and refine them over the years) to become successful. I recommend creating a checklist that reflect your principles and sticking to that list religiously.
Fundamental analysis crucially relies on understanding the three parts of financial reporting: the profit & loss-statement, the cash-flow statement and the balance sheet. Studying those from one of the numerous free online resources should serve you well.
In conclusion: investing is a intellectually rewarding endeavor (and I wouldn't want to miss it) but, and that is true by definition, almost no one can reliably generate alpha. So spend your time, effort and (!) money wisely.
I would recommend building a business / start up or teaching yourself programming. Over the long term you will make more money.
One thing I have learned is that most of the other people talking about the market are full of shit. There is so much misinformation and red herrings that it feels like seasoned investors WANT newbs getting lost in the spiderwebs.
Reminiscences of a Stock Operator by Edwin Lefvre
Where are the Customers Yachts by Fred Schwed
Nothing has really changed psychologically since those books. The same people are doing the same things for the same reasons, just with different numbers and tools. This will provide some background in those areas. Very much like music or sex (edited to add, or programming), young people like to think their generation invented the topic, but not as much has changed as you'd think.
Note that just because its hilarious reading what Livermore did a long time ago, doesn't mean you won't get thrown in jail if you tried it today. So these are like anthropological case studies, not preachy instruction manuals. Make sure you get that.
Aside from that I'd propose the usual critical thinking skills. Whenever you hear or read something: Follow the money. From his perspective, why is he telling me this? Where is this on the lifecycle of ideas from new (perhaps only to you) to conventional wisdom (may already be obsolete) to obsolete, and is this a linear time or circular time situation?
Finally bad people or bad motivations don't necessarily torpedo an idea. Take for example haircuts. Ask your barber how often you should get a haircut, that will be every paycheck please, because he's paid transactionally. Likewise, you ask your financial advisor or broker how often you should dollar cost average, because he's paid transactionally guess what his advice will be. However, corrupt as that may appear on the surface, it might none the less be correct advice, for reasons having nothing to do with your broker's revenue stream!
>What's my story.
My father was a chemical engineer. He got an MBA and switched to investment banking and then to financial stock analysis. Back in the 80s, he had something similar to ValueLine and would go through them looking for P/E and EPS filters. We had racks of these financial metric newsletters and a couple of interns running this from home. Occasionally I would help out. This was my first introduction to stocks.
My dad then switched to private investment banking. He would come home and tell us stories about startups, how he invested and so on.Then he started writing financial articles for newspapers. Mainly on Technical analysis. Some days, he would be too busy to do it and I would write the articles. I was his tech support for the graphical charting packages. The technical charting packages were also my "fruit fly"/muse for learning new languages. Every time I wanted to learn a language, I would re-implement my charting package. Dad fancies himself an astrologer so for a while there were articles on stocks and astrology. "You must be a Virgo - cause your wallet is so thick ;)"
At one point, he was the owner/editor of a newspaper publication himself and we had the union workers protesting outside our residence for a day on some matter. The newspaper died fairly quickly when we couldn't find advertising to support it.
One event from this period that sticks out. Like twelve years old are wont to do, I'd asked for a bicycle. My dad usually responds to these with - "If I invest in the bike, what will we get back?" I have better answers now. Anyway, he bought me a really unappealing cheap, robust bike that I was ashamed to drive with my friends. It never got much use.
So by the time I graduated college, I knew roughly what stocks were. I had written technical charting analysis packages, understood EPS and P/E and knew that you only put money into something if you get more money back.
For my master's thesis I worked on Genetic programming and growing technical analysis indicators to trade stocks.
This is a formidable head start but my investing record is quite pitiful. I understand a lot of the terms but not how to apply them successfully. I've found quite a few ways to fail and am now comfortable sticking with invest funds.
But I continue to invest and read up on investing. I believe it is the easiest way for me to reach my "magic number".And I enjoy the process. But most of my money is in index funds.
Advise:On reflection, I can recommend the following.
1. Get a broad 30,000 foot view of the different investing philosophies (Technical analysis, Fundamental analysis, value investing, special situations, Dividend investing, etc.). Evaluate these schools against each other and against yourself. For example - I started out as a technical investor, but it made no logical sense to me. So I switched to momentum investing and sucked at that. Now I'm trying value investing on for size. Some of these methodologies will fit your personality and others will not. The book recommendations made in this thread help. Random walk down wall street says markets are efficient so don't try to beat them. Fisher's book will have you picking stocks. Some of these arguments will resonate with you and others won't. Try on these philosophies. "Strong opinions weakly held" comes to mind.
2. For value investing - forget the technical jargon and Investopedia. Approach the stock from a HN/startup/VC point of view. Imagine you are buying a business. If this company asked for your money, would you give it? What questions would you ask as a VC?
- What is the market size?
- Are the users growing?
- What is the infrastructure cost?
- What is the exit strategy?
- Who are the competitors?
- What are the risks?
Shark tank does a good job making this sort of mental modelling accessible in video form.
You only need the finance terms to answer these questions. But the first task is to ask the right questions.
The problem you'll find is that most public traded companies do lots of things and it gets confusing. Find the 1-3 most important things to focus on or look for smaller companies.
3. As others have recommended, take a stock and make a recommendation. Write out an analysis of whether you would buy or sell. Then look at the analyst reports for that stock. Look at seekingalpha.com articles. What did you miss? What insight did you have that nobody else did? This is the hard work of having an opinion that cannot be done from videos. Investing is a contact sport for ideas and you need to understand the feel of the soccer ball on your feet.
4. Be realistic. What kind of returns are you expecting? Anything more than 10-15% is unrealistic in the early days. Even if the return exists, would you be willing to risk enough in that one opportunity to make an overall difference in your net-worth? This is where portfolio management comes in. The more you diversify, the less risk and return you have. The less you diversify, the more certain you have to be in your abilities. For those of us who are unsure, getting to that point of certainty is long road.
Good luck - you have a wonderfully interesting road in front of you that will keep you excited for years.
Since the fastest way in the market to make a million dollars has historically been to start with two million, in todays markets one would need to start with 10 million.
Today 99% of profitable market trades are automated. You will neither have the hardware infrastructure, technical accumen, or market/insider knowledge to EVER compete. You may eventually acquire a sufficient technical understanding. Individually you will never gain the other two.
If you want to "gamble" then I would suggest you figure out how much money you are willing to lose. If it is less than five digits, you will have neither enough for learning nor enough to survive setbacks. Initial minor choice: take this cash to Vegas rather than Wall St.
Once you have your trading account setup and funded, leave it alone for the next month.Watch market news. Read analysis. Join trading forums.Once you are reasonably fluent in the lingo and action, go back to your trading account.Second decision point: IF you are still interested in losing all that cash sitting in the account (think of what you could have used it for this past month, or how much it will accrue in your IRA/401k/saving account), then start tracking sectors which appeal to you.
Develop analysis to track stocks/sectors/etc in such a way that you feel you have insights to offer into the above discussion venues.
Now, the hard part. If you have spent sufficient time to gain understanding, and still have an interest in spending even greater time, then you are ready to start gambling for real.
You will have developed specific sectors/equities which you are interested in trading and so will have a reasonable idea about what to bet on. Do so with 1/4 or 1/3 of your cash.Decide entry, exit and bail out prices.Ignore these at the certainty of loss.Make a buy order, keeping your perviously intuited prices in mind.Wait for either a profit sale or a stop-loss sale.After sale, assess every step of you process. What was accurate? Wrong? Unclear? Resolve all these questions.
Repeat this process until you have no more trading cash available in your account.
Final decision:Either: scrimp, scrounge, beg, borrow and steal another stake; deposit into account and enter a lifelong addictive passion of passing your own money into the coffers of "others."OR: acknowledge you have neither the time, interest, expertise, insider knowledge, infrastructure access or capital to continue this gambling and walk away.
Option 1 will cost you money, health and familial ties. Option 2 will earn you great wealth and free time.
Good luck. Have fun storming the markets and don't say you weren't warned.
- 'The Big Short' & 'Liar's Poker' by Michael Lewis
- AntiFragile by N N Taleb (There are other's by Taleb, which I haven't read)
- Seeking Wisdom by Peter Bevelin (on lessons learnt from Warren Buffet & Charlie Munger -- Yes, few of the most richest guys, who gained perhaps)
I have also made some mistakes in investing. One so obvious mistake in hindsight, one was around 2007, when I moved a large portion of my networth from a single stock, to a diverse portfolio. Which was a good thing in itself, as I was moving it from all-eggs-in-a-basket to more distributed. But When the crash happened (world wide) I might have gone down 30%! The single stock, was comparatively down by much less. The good thing I did was not to do a panic sell in 2009. Though Discarded some stocks which were proven worthless (some down by 95%), just to avoid the pain of seeing them in my portfolio. But I kept the Mutual funds, which again started to come back to the original levels around 2011 and later on.
In restrospect, I should have reduced the risk fast. That is moved it all to cash. Then gone about investing slowly. By which I would have escaped huge downside (2008/2009). The problem is I knew the mantra already. But it got firmly registered after that experience. Another such golden rule is 'Buy when cheap, Sell when high'. Sounds very simple, but hard to grok it fully, unless you have felt some pain.
Having learnt that lesson. Now I keep most of my investment outside the stock market (exited during the rise of 2014). And keep only lesser amount around 10-15% in stock market. And that too only in index funds.
So IMHO, there is clearly no one size fits all. Investing and gaining from it is very much possible. Wonder if there is any vested interest in the mantra which gurus give i.e. invest only in mutual funds/index funds. Do they want others to not compete with them? :-)
But it does take a lot of time and years and pain to become good at it. And time is the biggest resource constraint, which perhaps we (the non-pros) all have. So at present I like to read everything I find on the topic. But decide to play it safe (i.e. fixed deposits, index funds, and similar). As once you are in the game i.e. investing in stocks/instruments which have huge upsides/downsides and hence riskier. You need to be more involved. And my personal experience its very difficult to do that, with things like programming and trying to grow your own business.
Hope this misc bit of reading pointers and micro experience share, is of tiny bit use. I am ever interested to read as much on this topic - views, articles, particularly the insights people learn from experience.
 Had got this reco via Derek sivers https://sivers.org/book/SeekingWisdom
A security policy is much easier to prove correct if authorization and authentication stem from the same place. You don't have to aggregate many systems and then try to fold that data down before analysis.
I prefer this centralized authentication to be restricted to a particular realm (like a particular website/company) and not universal though.
Consider an intranet. If you have one password to log into all of your enterprise applications you are going to know how to log in and you will use all those applications.
If you have 20 different applications you use at work and you have 20 different logins, probably some of those services will end up in a state where you have to bug IT people to get a password reset when you ever need to use them. There will be others you just don't use at all, and maybe that suits management because they'd rather you didn't take time off from work anyway. (ex. application you use to claim time off from work)
It gives you a lot of benefits.
- Easier to scale securely. Adding 100 auth'ed services that may or may not work differently is a recipe for disaster. Ad-hoc security by people who aren't security experts generally does not work...And maintaining it will not be easy....
- One way to auth. Developers make fewer auth mistakes this way. For example, if you are a Go shop, you have a company wide auth package that can be used by everyone. Mistakes are limited this way. Fewer vulnerabilities. Less developer friction and more productivity, not having to have developers worry about auth themselves.
- Control. Revocation and adding new permissions is hard if it is not central. How many services have to restart when someone quits or a service is hacked. How do you even know how to revoke something if some auth scheme is built where one service can talk to several services with the same auth token? As complexity is added, the process is more unclear. This leads to mistakes.
There are more but these three bullet points came to mind first.
Theres an argument to be made that some datacenter topologies have segmented their networks such that theres no reason for clients to authenticate. Im generally not a fan of this approach because over the years Ive come to believe there is untrusted code running in the perimeter
1. "Certain Network Topologies" should be "Most", or at least "Your" network topology. And this statement doesn't need to be confusing: You're going to run sensitive services on your network, you're going to run databases, and those services really shouldn't be exposed to the outside world. Even your applications should ideally not be exposed directly to the outside world, they should be proxied by a load balancer / network gateway that forwards only expected traffic to your service. Make your LBs default to not allowing traffic so that you can confirm this. Use services like ELB and VPC if you're in Amazon.
2. "Untrusted code running in the perimeter" is a situation that you should A) control, and B) aggressively be defensive about.
3. If you're going to go all the way with service auth, you need to think about how safe your secrets are. If your code is shipping with the secrets, then you're really gunning for security by obscurity. Keeping secrets on disk is a security hole. Heck, even keeping plaintext secrets in memory is not fool-proof.
I liked the article, but generally speaking, you really do need a comprehensive solution to service-to-service auth if you want to go down that road, because taking shortcuts is going to just expose you to a ton of downsides without even attaining the upshot. And regardless of if you set up service-to-service auth, you really should be segmenting networks anyways for a host of reasons, and layering auth on top of that. So these two things are inter-related on some levels, but form a layered security approach together :-).
To me it sounds like recognizing a good solution to the problem and implementing it. Unless you have a good counter-reason to offer why a centralized authentication service is a bigger problem?
(Note there is a sliding scale on how often you need to hit the security service. You can have every single request going there, or you can have it give out tokens with varying permissions your services then can validate themselves. Cloudflare's blog recently described how they use internal CAs to authenticate services against each other, basically only requiring a service to once get a certificate, there are concepts like Google Macaroons, ...)
>There are several open source security services out there. Use them!
Something like https://www.vaultproject.io/ would be a solid foundation for either running your own CA with narrowly scoped / time limited TLS client certs, or managing secrets for generating signed identity assertions, e.g. a JWT.
That's one of the reasons I've always been skeptical of centralised anything. It's another potential group to fall out with or point of weakness.
If you're worried about infrastructure being online, issue certificates and trust certificates signed by your CA.
Centralized has the fundamental problem of power and choice: witness how facebook, amazon, twitter, Apple, etc. can do whatever they want in their ecosystem. Facebook's users aren't going anywhere, they're essentially trapped if they want to get updates from their "friends", so they'll have to put up with whatever choices the social network makes.
But the biggest power imabance is with developers / publishers. Facebook, Twitter, Amazon, Apple, etc. have all been known to push around their third party publishers, compete with them, and even simply disconnect them whenever they want. Those publishers cannot connect directly with their users without a decentralized login.
And if you're into privacy, you might want to consider how much easier it is for state actors (and hackers) to have backdoors into just one server farm that has everyone's auth information rather than if profiles were stored like the web -- each person could choose their own host.
Distributed auth is possible. What you need is a distributed protocol and reference implementations. Something like OpenID or oAuth is a good start. You can sign up with network X and then use X to auth with other networks. Sadly, xauth was discontinued and everyone assumes Facebook, Twitter et al can be the only OpenID or oAuth providers.
What we need is a new protocol, and that's something we've been working hard on, and have successfully designed.
It doesn't even require you to share your user id, name, etc. with the consumer sites you visit. They can be instantly personalized for you and show you all your friends without knowing who you are. When you are ready, you use oAuth (or something essentially similar) to start building up your profiles in other communities.
No third party can know that user A in community CA authenticated as user B in community CB, unless you sharethat information. You know that thing, "Your friend FooBar is on Instagram as Baz?" That's stuff I might not want everyone to know if Instagram is, say, a porn site. A few years ago, there was a huge uproar about Facebook's "instant personalization" with "trusted partners". Today, it came back and no one cares.
Truth is, we are giving up our power as consumers, and even more so as producers who eventually build our own communities on the back of large, entrenched, centralized communities. Do we really want to centralize power when we see all the bad stuff it can lead to? (Internet 2.0 in India because FB is the only option, Net Neutrality fight because telcos are too centralized, etc.)
I say, once we get the tech right, it can be replicated. After all, bitcoin distributed money. The Web, Email, Git, etc are all distributed. Why not social??
Also, independent contracting is often a better option than employment in most parts of the country, but you have to be independent (1099-MISC, never W2). Being a W2 at a consulting company is just as bad as anywhere else. Independent consulting will get you a 2x bump instantly assuming you can find a full time gig but that's usually not that difficult. Furthermore, as a 1099, you'll be able to put away far more in retirement savings. I recommend an LLC with a 401K (not SAP), max out your personal contributions and then kick in another 6% from your 'company'. You'll be socking away ~50K in retirement alone this way while lowering your taxable income. Compare that to your 16K/year max as W2.
Another trick: if a company ever offers you a larger than usual bonus for some reason (i.e. retention, goal met etc) leave the next year when it shows up on your W2 and ask the next employer to merely 'match' your current W2 without breaking out base salary and bonus. I've scored 50% pay increases this way.
Following the above methods, I was making $180K+ at my 8 year mark and $230K+ at my 12 year mark. Most of this happened in the midwest although I currently live in the bay area.
Got 90k job out of college in NYC. Worked on a legacy PHP app with some Python, Java, Hadoop occasionally in there.
Negotiated salary to 100k + 10k bonus after one year and good performance reviews.
Next year asked for a bonus increase. 120k total now.
Started getting bored at the job. Asked around, got a 135k offer from another company. Went to my current employer and said if I don't get 150k I'm leaving. They said they could do 140k. I went back to the other company and told them their offer and they gave me 150k.
It has less to do with skillset or language choice than it does with just being able to negotiate and iterate on offers and take the opportunity when you can.
Scott Adams talks about how one can dramatically increase their odds of success by learning multiple skills. You might imagine adding languages to your skill set is a smart play. Learning the Art of Negotiation on top of those skills is a force multiplier.
Incidentally, Adams book is a brilliant read, full of solid, unconventional career advice > http://www.goodreads.com/book/show/17859574-how-to-fail-at-a...
Sorry for not mentioning what areas I had in mind. I was talking about friends in Dallas, Atlanta, New York and Raleigh among others.
We are talking 5-8 years of experience.
I have seen and tried to follow the advice in this thread and it has not worked out.
Maybe I'm doing something wrong, or I'm just not good enough yet. I get a lot of interview calls, but the salaries offered are nowhere in the ballpark of $150k.
Also, every friend of mine, that I have spoken to, is doing either Java or C#, none that I know mention Python. When they offer me referrals I politely turn them down due to lack of experience in the Java and C# stacks.
I'm not a ninja or a rockstar but I get work done. My current role is one that requires me to learn all sorts of new things and thus my resume is a splattering of all kinds of skills.
I just want to stop worrying about my future and focus on enjoying family, hobbies and hobby projects instead. (But then who doesn't?)
It would also help me greatly if people could mention if the advice being given has worked out for them also.
I don't want to sound mean/ungrateful/rude, I really do appreciate all the help.
I ended up doing Groovy, then Java, and now I'm in the government version of "Enterprisy Java" and I feel stuck myself. 150k isn't that much if it leaves you empty inside.
That said, due to its high cost of living, $150K isn't that outrageous in San Francisco. You can use online cost of living adjusters to see what the equivalent salary would be in areas you're familiar with.
Most programers will tell you that the pay scale in software is like a hockey stick curve. Up really fast then flat line. Therefore, you move to the top of the S curve and then stick around long enough to approximate O(n).
You have to continue to self-learn and improve yourself.
I'm not a full time front-end dev, but I find the trick is to keep an eye on what's going on, play about with the bits you find interesting when you have time, but remember that keeping up doesn't necessariily need to involve using any of it - you don't need to use any of it until you're good and ready, just be aware where things are moving when it's time.
I'm developing React apps at work at the moment and my experience of it is that it's easy to ugrade React because they usually deprecate a release ahead and they don't release all that frequently. Meanwhile, I've only played about a bit with Mithril and Vue, took inspiration from Ember's tooling and am keeping a wary eye on Angular 2 because it'll probably end up getting used somewhere where I work.
Extracting all your tools out into your own tooling also helps - all my Webpack/Babel/Karma config and dependencies for React apps, React components and regular npm modules is in one tool and my complete ESLint config is in another. Neither is using the latest and greatest of anything (currently still on Babel@5, npm@2, Webpack@1 and ESLint@1) but when I'm good and ready to upgrade I only need to do it once.
If you're jumping on different projects, well the people that set them up used different tools. It's no different than jumping between a .NET C# app, a Rails app, or a Spring MVC app.
But if you spend a lot of time in the Frontend then it becomes fairly obvious about switching to new tools and frameworks. Builds tools are starting with better defaults, react is making it much easier to build intricate UIs without complexity.
Write about the "why's" instead. In other words, try to answer the big picture questions about serverless architectures without getting bogged down in the minutiae of what is state of the art in early 2016. Try to picture what someone in the year 2018 or 2020 would want to know about them, and write about that.
My hunch is that collecting the stories from several individuals will yield some tremendously interesting ideas.
Otherwise, why not just agree in writing to blanket cross license all the IP to each other in exchange for prohibiting any future claim by either party against the other and call it a day? P
NDA's and IP assignments are only meaningful if you're prepared to lawyer up to enforce them. The more complex the situation, the more it is likely to fail an investor's due diligence anyway.
2. Ledger for CLI badasses.
3. Org-mode because time series data is essentially lists with time stamps.
4. Paper and pencil, because if that doesn'twork, then the issue is not technology. It's habit. Personally, I'd go with paper and pencil to develop a workflow before fooling around with technology.
But, the problem with going over budget boils down to one of two things: poor estimates or buying the job.
Lastly, if you're billing hours internally against a fixed price externally, there's always going to be an impedance mismatch. I know that HN'ers love to promote fixed price, but if it doesn't work then don't use it: bill time and materials instead.
AMA history: knowyourmeme.com/memes/ask-me-anything
"With a 16GB machine, it takes my test suite 5 minutes to run. With 4GB, that suite runs in 20 minutes. I need to run it on average, 10 times a day. So by giving me the 4GB machine, you're having me sit idle for an unnecessary 15 minutes, 10 times a day. So that's 2.5 hours per day that you're paying me to spin around in my chair and surf HackerNews. That's X wasted dollars every day, which is significantly more than the cost of the upgrade from 4GB to 16GB. So you'll save money by giving me a faster machine".
If there's a way to speak dollars-and-cents to the bureaucrats in your org, then there's a better chance of them approving your request.
Things will not get better, as management has costs to cut. Your work equipment is one of those costs. If it was up to them, you'd be shoveling with 3 spoons instead of a shovel, since "it works for most", meaning "we only assign shovels on a 1-1 basis so that we wouldn't need to spend bigger amount now." What are your salary raise prospects at such a company?
That being said, 4GB is stupidly low for a development machine and that should be alarming for the development team (6GB is not much an improvement).
I would argue the "works fine for most developers" point. What works now (the current state) is certainly not going to last. 4GB is already too low and it is only going to get more difficult as the requirements increase (bloat is a constant).
The conversation should be "what is the practical life of this hardware and do we intend to upgrade when it runs out." You should think about performance hits (in the people sense, not hardware sense) if these environments are abandoned by your developers. All hardware purchases have an effective life and what you've described is a purchase which will barely last another 12 months, imho.
Unless you're offshore and your wasted time is not as valuable, that's a poor VDI use case that doesn't make sense
Fight it with vendor recommendations.
But yeah you need twice that RAM, minimum.
I really wanted to ask if I could donate my old netbook and remote into that.
I used to have to upgrade my own machines. For years. Monitors and RAM. I haven't had a place that gave me anything less than 16G for years now, though.
Gallup does surveys for businesses and one of the questions they ask is "Do you have the right equipment to do your job".
If your workstation is slow, or you have to deal with OOM issues, and can't get your work done, that is something that needs addressed not by guessing, but my management doing their job and providing you with the right equipment from the start.
If the company isn't willing to provide you the right equipment based on what the employees think and not just on what one person says based on hearsay, than I'd question if that is a good place to work.
But then you wouldn't be running Eclipse, Chrome and WebLogic locally on them, so that's probably not the case? And even Chrome alone can easily eat more than 4 GB, so that's kinda laughable for any kind of dev work.
You'll also likely be going up against Informatica if you want to play in the Enterprise space. That said, I'm also interested in a solution like yours as we're rolling out our own automation system but need to keep track of things for compliance reasons.
Would be happy to have a chat.
If you format an XML or JSON file with one field per line (or just use YAML) git itself should fit the bill perfectly.
Now, I do see lots of room for a git-like tool targeted at specific existing binary file formats. Microsoft Office and Photoshop files come to mind off the top of my head. (I believe that such tools already exist for those particular formats, but they're expensive and currently have low adoption.)
On paying for this. When data operations are built around pipelines, it's often easier to re-run the pipeline or restore a snapshot. Which requires a good server, but not a service. So before paying, I'd check why the new tool is better.
However, any system would have to be available on a private internal network for most places.
To give an idea of what I mean, see: http://karpathy.github.io/2015/10/25/selfie/
this may not be exactly what you want - it would tell you "the branches were not taken during this run of the program", but not "it is logically impossible for this branch to be taken for any run of the program"
Case 1, Total Compensation. Amazon does "total comp", which is your base plus RSUs. Suppose your grants were rather large, or "timed" at a downswing for AMZN. Your current vesting schedule for 2016 could exceed the planned target & salary band. I find no base adjustment whatsoever mildly surprising. But I would not be shocked.
Case 2, performance based compensation. As amzn-tway8 also mentioned your yearly compensation at amazon is related to your annual performance review. Read and understand the definitions of "Performance Rating" and "Leadership." Your manager will have discussed this with you in your annual review. Average and exceptional performance reviews will yield relevant compensation adjustments. Individuals with a very low performance review can expect a low, or possibly no, increase.
None of their Google Cloud services are working for me, but the page says everything is operating normally.
This is not the first time this has happened either. Their status page has been truly useless. There is often degraded service or services going out for an hour or two with nary a blip on their status tracker.
This is not what I'd call "Normal", Google. You can do better with monitoring services, and you know it.
"The issue with Authentication Services should have been resolved for all affected projects as of 07:24 US/Pacific. We will conduct an internal investigation of this issue and make appropriate improvements to our systems to prevent or minimize future recurrence. We will provide a more detailed analysis of this incident once we have completed our internal investigation."
Generally Oauth is for authenticating to a 3rd party service/client that you are this account on this service. An API key is authenticating you via your client on this service. API keys are just like passwords. Only the user should know it, whereas OAuth tokens can be safely given to 3rd parties.
Username/password is not mutually exclusive to API key and OAuth. Also, API key is also not mutually exclusive to OAuth. All of these things can be intermixed for different purposes. In some cases, API keys are only used to identify the client, and not for any type of security.
> mainly because I want to learn how to do it
Don't do this unless the security isn't important for this project. Writing secure code is really hard. You don't write an SSH library every time you need SSH, do you?
I can also tell from your question that you don't have even the most basic understanding of web app security (saying that OAuth is complicated for "nothing").