Docker ID: rockymadden
368 karma · joined January 4, 2012
Docker ID: rockymadden
I help early stage startups deliver on their technical milestones with progressive development and solid communication/project management. I'm an FP-oriented JavaScript developer with direct influences from Scala, Haskell, and Clojure. My passions lay in the lower-end of the spectrum, with particular emphasis on microservices, stream processing, machine learning, natural language processing, and expert systems. I'm also a data science practitioner with a heavy background in both frequentist and bayesian statistics. Currently focusing on freelancing with React/React-Native/Flux-like frameworks to develop unified web, iOS, and desktop experiences.
https://github.com/rockymadden
https://dribbble.com/rockymadden
hn@rockymadden.com
- $115/mn for a 64GB ECC, 3x Intel SSD, Xeon E51620v2, 500Mbps, etc
- $50/mn for a 32GB ECC, Intel Xeon W3520, 4TB SATA
- $15/mn for a 4GB RAM, Atom N2800, 1TB HDD
I scale differently as a result; huge gobs of RAM/SSD/CPU is easily within reach. For instance, I can use Redis Cluster as a primary data store with then op/s an order of magnitude higher than most might be used to.- From the creators of this site and its previous version
- After being compared to Duke Nukem Forever
- "I’ve never agreed to having my face used on the itemz website"
- "There are millions of task management apps. Creating another one is just stupid."
- "I don’t use this app and I‘m not planning to start"
Despite OP saying otherwise in this thread, this has to be a joke.. right? Every page/video seems to have things like this. OP, if you are serious get a native english speaker (you said you weren't one) to go through the site.
Districts often face even more fundamental problems, such as each software system being a silo to it's own data and being very hard to cross reference with other systems. SISes, LMSes, HR, and dozens of smaller systems existing in their own world. Many questions one might want to pose needs data from two or three of these. So, questions like `is Steve a much more pronounced risk of dropping out of high school` are hard/impossible to ask (depends on the software systems and data collection practices).
- 4 to 6 hours of dedicated/uninterrupted work per day
- 6 to 7 days per week
- Wake early, say 05:30, and start work right off the bat
I looked at my own GitHub work history to see when I was most productive and also read a book about how many of the most profound creatives worked in their own lives. Both suggested such a structure and it allows/addresses many of your concerns (i.e. I also have a child, need to do chores, don't want to count hours but productivity, etc). The thought being many work best early in the day, you only have so many hours in a day you can focus on hard problems without wasting time, and consistency is a virtue.Lastly, there does seem to be a mindset of `I want a stellar developer to talk with but don't truly value their time` (e.g. the $10 for 15 minutes of their time you mentioned). Not always the case, but it is definitely not common to see freelancing type rates. So, you end up donating your time, which isn't always possible to do from a fiscal standpoint.
- Mission which truly helps people and focuses on the end-user and not simply the bottom line
- Working with extremely smart/talented people, who don't take themselves too seriously
- Robust development practices, to the point you can feel proud of your work and allowed to be the best in your field
- Treats employees as adults and also truly value their work/life balance (i.e. happy employees are good employees)
- Money
I'd take ~40k less a year (e.g. 85k vs 125k) if it meant being truly happy in my career with a company that meets the items on that list. - Create an Amazon seller account in which you have absolutely stellar reviews and customer service. A perfect five stars is what you are aiming for, which is pretty easy to accomplish if you try (e.g. with roughly 50 sales over the years, I only have one 4 star review and all others are 5 stars).
- Purchase the Mac product(s) you want.
- Ensure you keep good care of the laptops and also keep the original boxes and accessories.
- When Apple comes out with a new version, immediately buy the new version(s).
- Sell your old version(s) via your Amazon seller account.
Personally, I buy a low-end portable laptop (e.g. 12-inch rMB or 11-inch Air) and also a high-end laptop (e.g. 15-inch rMBP). You will find that the low-end of any product by Apple will retain their value best. However, even purchasing high-end (but non-customized) product is still pretty solid. This advice also works for iOS devices. On the whole, it costs me ~$750 a year to "lease" both the laptops. For example, I recently purchased a new low-end rMB for $1299. Given my seller account, I expect to resale the same laptop for ~$1099 when the new version comes out. So, I get a new rMB laptop each year for ~$200.You will find certain product lines hold their resale value better. For instance, iPads, 13-inch rMBP, and both Airs hold their value well. On the other hand, iMacs and Mac Pros don't hold their value very well. In the middle you have iPhones, 15-inch rMBPs, and Minis. Customized add-ons (in which you can't go into a store and buy) are a huge no-no with this approach. The depreciation cost is just too high.
Heya, I'm Rocky. I'm an avid open source developer, mentor, and lead developer with over twelve years experience. I'm an FP-oriented JavaScript developer with direct influences from Scala, Haskell, and Clojure. My passions lay in the lower-end of the spectrum, with particular emphasis on machine learning, natural language processing, expert systems, and other forms of artificial intelligence. I'm also a data science practitioner with a heavy background in both frequentist and bayesian statistics.
Currently focusing on freelancing in:
- React/React-Native
- Flux/Reflux/Fluxible/Fluxxor
- Electron
- Unified web, iOS, and desktop solutions
I've helped several VC-backed startups successfully deliver React/Flux solutions (including isomorphic).-----
https://github.com/rockymadden
- React/Flux: It IS super new, I just assumed if a company choose/moved to it and are actively coding with it that they would know the basics of it. Certainly wasn't expecting core contributor knowledge by any means, just that fellow devs have read the docs and avoid plainly stated bad patterns in said documentation.
- Functional Programming: Again, I only mentioned FP because they are core concepts for React/Flux. They are also highly encouraged/required in certain scenarios: https://facebook.github.io/react/docs/advanced-performance.h...
- Security: There is no reason security needs to slow down a project dramatically, if done right. End-user security should be taken seriously and not be something to be tossed aside because it is "hard". Basics get you a long way.
- CS: Good idea on the premium. Though it is often beyond a simple conversation when the concepts of recursion and basic data structure performance/usage is an exotic topic.
- Devops: Solid points, however I wouldn't say it is anything close to a bankrupt concept. Ansible and Salt for a day or two and you have completely manageable, repeatable, and solid approach to your infrastructure.
We agree on what the biggest concerns are. Oddly, I often see nearly everything missing, those being of the most concern.
Functional JavaScripter seeking React/React Native/Flux work with technically strong and collaborative teams. Twelve years as a developer, served as dev lead for top US trafficked sites, additional background in machine learning/AI, bayesian/frequentist statistics, data science, horizontal scaling, micro service architectures, Scala/Haskell/Clojure, etc. Successful react projects with a couple VC backed startups, wanting more.
GitHub: https://github.com/rockymadden
Dribbble: https://dribbble.com/rockymadden
Personal: https://rockymadden.com
Reach me at hn@rockymadden.comWith Ansible, I spend no more than an hour a week, amortized, maintaining both the hardware and administration. I assume nodes for any specific role will fail, I only scale horizontally, I always have redundancy for every role, I stay off disk as long as possible (heya 512GB RAM redis cluster), etc.
You bring up a valid concern about the race to the bottom, which is exactly one of the things I want to avoid. The thought around the minimum rate information was to inform others about what type of level of compensation one would need to even consider work. I think I might rework this right now and also inform folks that only developers with rates above XYZ are allowed.
I welcome any feedback on the concept!