802 karma · joined May 24, 2011
I commute most days, usually several miles. The only time I prefer car or train is when its raining, which is rare.
I've now lived here for almost 15 years. I've traveled all over the world, and LA is still my favorite city of them all.
It's a cruel mistress one day. And a wondrous utopia the next day. Never predictable. Home.
Invalid template todo-inputHaving said that, I agree. It was likely a huge mistake to turn that down. FB has whats app, and there is now so much competition in this space its uncanny. From iMessages, to FB Messenger, to Whats App, and smaller players like Kik, it seems like a congested market.
I used to be very paranoid about saying no. I actually recall the first time I did. I was running very low on sleep, and had been for some time. I needed a breather, but I just couldn't risk losing my reputation for always-being-there-and-always-getting-it-done.
After I (politely, but firmly) said no for the first time. It was a breath of fresh air. No one criticized me, or stopped hiring me. In fact, I think a few people close to me started working with me more, probably because I was getting more sleep.
So, don't be afraid to say no. It takes some practice, but you'll get used to it.
So on the surface this seems like a great idea. Has anyone read the decisions surrounding apple's desire for people to not use a UDID? I'm curious, if this is 100% within the OK zone, where one could depend on it?
This ultimate simplicity, and encouraging programmers to write simple code (sometimes, I know, at the cost of having more tedious code) is not all bad.
The "dogma", and the "it's too complicated" parts of go, while sometimes are indeed a frustration. However, I feel like it has kept the language and the culture surrounding the language largely simple. So both a pro and a con in my opinion.
Having worked with go for several years, on many small project and a few large ones. The pros outweigh the cons.
One of the bigger ones for me is simply understanding other people's code rapidly. Go projects seem extraordinarily easy to understand without spending hours reading code. When I am in a position to support/operate/scale/troubleshoot other people's code, which is part of my role, this has been a less challenging experience than other languages.
Yes, if I go to my absolute favorite coffee shop in town, it is superior to Nespresso.
But, in comparison to instant coffee (in my humble opinion), it is night and day, and its miles and miles ahead taste wise than coffee bean or star bucks.
I am a big fan of Nespresso. It saves me a lot of time, a little money, and consistently provides (for my tastebuds) better coffee than I can get within a 3 mile radius of where I live. (somewhere in los angeles).
I buy capsules 50 at a time, for .70c a capsule + 7 dollars shipping, no tax. So that comes to about 42 dollars total, or $0.84 per cup of coffee.
That enables me to consume 2 capsules per day for $1.68 per day, or $11.76 per week, and usually I drink less on weekends.
Coffee sold locally in the stores of high quality here tends to be a minimum of 10 dollars per pound, and normally to really "select" one I prefer, would cost around $13.00. I like to brew my coffee strong, and still would drink 2 cups of coffee per day, so this tends to run out for me about 6 days of my 7 day week.
So while its slightly cheaper for me to drink nespresso, its almost the same price.
But, with nespresso, I go from rolling out of bed to the kitchen, and within 30 seconds I have really good tasting coffee, no mess, and I can easily select the type of pour I want, capsule I want, etc. It is truly extremely convenient.
Furthermore they are an example of outstanding customer service. My machine had a malfunction once. Called them on first day, they over-nighted me a replacement machine while I sent my in for free repair. Got the original back a few days later. Hardly any downtime w/o a machine. Total cost: $0.00, and the machine wasn't even under warranty. Obviously they want to keep selling me coffee. I have no issue with that.
Finally, they offer recycling programs which work good, so I don't feel like I'm being a bad citizen of the earth by supporting them.
I see it as sort of a Spotify of coffee. You pay repeatedly one company for good service, and if it meets your needs, it is going to save you time and money if its something you do a lot. For those that are into coffee on a deeper level, is sort of those who are into music on a deeper level.
For me with regards to music, I am a bit of a control freak, I like to know what bit rate file I am playing, I like to back them up carefully and managing my music collection I invest time and have lots of pride about - so Spotify (While I generally like their service), is not for me.
The same can be said of Nespresso. If you love the entire process of making espresso, getting into the gear, and the execution of how its made and putting that kind of time into it and getting a specific kind of joy out of it, Nespresso would probably not be the right choice.
I guess I have enough hobbies, but I still really like well made espresso at home. Nespresso is right there in that intersection.
Also, ubuntu has a project called JuJu. Could be confusing I supposed. ( http://en.wikipedia.org/wiki/Juju_(software) )
Logging in would be cool, or someway to see what would be in my feed. Often I start my day just playing my feed on SC to see all the new stuff coming in.
Likes are perfect, exactly as you have them.
Yes, there is parts of the job to dislike. But its possible to arrange yourself in the scene where that is minimized. If you take out some of the negatives, and you still don't actually enjoy the task of developing and debugging and supporting software, then its probably the wrong career for you.
Some of the examples the author lists like dealing with awful error messages, or the snow flake / shoveling snow are things that I have truly come to enjoy about the job. At some point after many years of experience you get better at avoiding situations, and therefore get better at writing more useful error messages and software structure. But there is always going to be fresh blood, code that is overly complex or poorly thought out if you stay in the industry long enough.
There is something I find truly satisfying helping teams evolve from shoveling snow in their picasso-esque unorganized pit of despair, to winding up on the other side of the fence, with a functioning, maintainable codebase and many contributors contributing in a positive way. This too - this evolution of improvement, is another part of the job to enjoy.
If you don't learn to take some level of satisfaction out of these more negative times, you will, as the author said work 15 hour days and feel like satan is dining out of your skull.
In other cases, if you put yourself in a situation where you are completely irreplaceable and indispensable, that is another thing that you have to learn to avoid. While this can feel really validating and positive because you get a lot of "well we better hand it to Bob, he is the only one that can fix this!", you should enjoy the spotlight, while simultaneously figuring out how to make yourself replicated and not a single point of failure. Sometimes this involves hiring people, sometimes it involves training people on your team to improve so that the work load is spread. If your in a situation like this you simply can't escape, its possible its an unhealthy situation, and you should really ask yourself why you put up with it for more than a short burst here and there.
In any case, there is always going to be parts where you feel like satan is dining in your skull. But with any luck and perseverance these shouldn't be the job description, in my opinion.
Would be great if there was a basic way to see what percentage or time your in of the track, like (15:22 / 82:44), and it would be great if it could login to SC so that I could see my own feed of new content coming in.
Having said that, don't add too many features, because where this shines is not having so much bloat. I love SC and all their features, but when I am just working and listening to music I don't need fancy album art, comments, notifications or anything.
Really cool idea.
It's not the worst idea, but here are some thoughts to consider:
* concurrency and locking
Databases are good at giving you a consistent view of data. Some are better at it than others. Depending on your application this may be more or less important to you. However, how often would it be possible for your application to have multiple requests that come in. How would you deal with if 2 requests write to the same file in s3? Which one will have the accurate representation of your data?
To give an example, lets say (step1) request A comes in and pulls down this json stored in s3. This request turns into a subsequent request (step2) to store the data in s3 (lets say a value in the JSON needs to change.) Meanwhile, another request session is started, request B that also pulls down a copy of the data. Lets say request B does this in-between step1 and step2. So then on step 2 of request B - you are potentially overwriting data that you did not intend to.
* performance fluctuation
Having used S3 extensively, I can tell you that its performance varies. What if your 400ms request goes through a 15 minute period where they are 4000ms requests. Stranger things happen. S3 is an extremely reliable system in terms of not losing your data, and generally working all the time, but performance varies. With each request that takes longer than you think, resources in your application (file descriptors, cpu burn, etc) pile up. If your application can sustain itself comfortably with these upper levels of latency you would be fine, but this may trigger downstream impatience with the users of your application, causing them to refresh data even more.
* querying and features
S3 is just a key value store at the end of the day. Maybe that is enough for your application. One day however, if you decide you want to know how many items in your database have a certain value, or how many were created on a certain date, you have no option but to really download the entire bucket iteratively from S3.
S3 doesn't have a good way to even estimate the amount of data in it. Clients that do this have to iterate over the contents of your bucket, and if one day the data grows to 100GB, this is a slow task.
In short, S3 tends to lend itself better to data that doesn't have as much concurrency issues, or data that is mostly static. However, if there is a will there is a way. If it were me, I would be most worried about the lack of database-like features, and secondly worried about the concurrency issues, but it does depend on your application.
Cheers
it really depends on your needs though. I use it as my portable machine and it goes wherever I go when I'm on the go, which I previously had an 11 inch air for. Coming from that it's an enormous upgrade.
The battery lasted me 7 hours yesterday of constant use, and the screen is the best screen of any laptop I have personally used. it's not really a widescreen anymore which helps with my terminal experience greatly.
My normal workload includes 50% terminal.app, 30% Xcode and the rest is split up between instant messaging and emailing. so I don't desire or need to run things like video editing or VMware. I use an iMac for that stuff, infrequently.
so for an OS X based machine that is ultra portable and runs terminal well, I'm not sure why you would be better off waiting. it's a great product.
In my experience managing and being part of various teams and projects for over a decade, I have found that a senior level developer that gets 4 hours of productive work done each day (over a week average, often not in one spurt, depending on the individual) is worth his/her weight in gold.
I always try to encourage 40 hours a week of being online, available, dealing with meetings and whiteboard sessions, but 1/2 of that devoted to heads down work like coding or designing. Often many people that are extremely valuable end up getting less than 20 hours a week of real focused work done in my experience.
"Sales representatives, service managers, field auditors of all varieties have not been adequately served by the computer industry in pushing laptop computers. As the technology of these machines, particularly of their displays, improves, and as their price declines, a lot of briefcase computers will probably be sold. And as the software that is capable of turning them into true satellite offices becomes refined, they will probably even be used - in fact, profitably so."
I'm hearing another prediction, that "a lot of briefcase computers will probably be sold." if things like displays and software improve.
Not sure who is calling this a wrong prediction, but the article leaves us with more than a gist of laptops weren't working out for the common business in 1985, but they did not explicitly state that they were never going to work out.
if I have a function that returns an interface I can grep who is calling it and probably digest what it is within a few moments and probably 2 or 3 files of code.
with java I find its so once you get through the factories, abstractions, and more, I have never found what I'm looking for in 2-3 files until I am more intimate with the code base.
I'm intimately familiar with the jvm and app dynamics and they do have wonderful tooling.
but, without that tooling I would be really paddling upstream.
call me old fashioned but I like simple tools, and golang I can profile faster and find bugs sooner. I have supported critical infrastructure on both platforms ( Java for many years , golang for 2) and it is not a hard choice to make for me, even with app dynamics and similar tools.
yes go lends code to be verbose and simple, at times feeling like you must make things too much so, but the rate at which I can understand what someone else is trying to accomplish and vice versa, I keep choosing golang, and it's verbosity.
at the end of the day, for me, verbose and simple is preferred to elegant and clever. to an extent, of course.
I like to break up tasks into what I hope is achievable in 4 hours. Always assign yourself as much (or more) of these sized tasks than those your assigning others, if you don't want to appear that your only a manager.
Re-evaluate these sizes often. Especially with a new project, new team, or new person. Maybe due to something you did not foresee right out of the gate, this 4 hour task is really a 16 hour task. Or possibly the other developer is working hard, and learning fast, but you just misjudged how quickly they can complete it in. In this scenario, the next time it comes to split up work (or if you really over-shot, you can re-split up what you gave them) remember this metric, and size it a bit smaller.
Depending on distractions, and how well the above process is tuned, I only hope for 1 of these 4 hour issues to be completed per day, while at the same time, looking at it over a week or two average, not daily, as many programmers do not work in a predictable linear fashion.
Over time as engineers progress and grow at their craft, what they may have been able to do in 4 hours, might be 20 minutes. As you work with others you will get a feel for this, and become more tuned into other people's forte's. Not everyone is good at CSS for example, even if you know how it works. So its not just about skill. The longer you work with people, the better you will get at carving out tasks that work for you and for them, and for the team.
So in summary, experiment with it, give yourself as much work, and in the same manner you delegate tasks to others delegate tasks to yourself. Re-evaluate the size of these tasks often, and try to create tasks that others can get done in a reasonable amount of time, so that they get the feeling of completing something.
Not everyone can be given a big gigantic month long task and not get lost in it, and on the other hand, tasks smaller than 4 hours, really start to feel (and take the energy) of micro-managing. The more senior the developer that has proven they meet goals on time and communicate well, these can be relaxed a bit, and you might find someone really prefers 2-3 day sized tasks, but can also be reliable in this manner.
Finally, ask them. You might be surprised.
If you have developed software in go, and after a couple months you aren't finding its saving you time, or at least pleasant to work with, maybe its not for you.
I feel like it is similar to C, but more opinionated, with much less rope to hang yourself, and often things I would have used C or Java, I find doing them in golang saves me plethoras of time.
It is opinionated, but for me the aha moment was after I learned enough of the standard libraries to feel comfortable in the language, I find myself getting things done at lightning speed, and it has performance that is as solid as the jvm in your average use case.
I find the code is also pleasant to read, and the language lends itself to writing verbose, simple code, which I find easier to debug than overly abstracted systems.
Most of my work involves building server applications. I have deployed 4 golang apps this year. One is a pre-caching system that concurrently queries a bunch of mysql servers and caches data into redis. Another is a replication system from couchdb to postgresql, and the other two are slim restful api applications that sit in front of elastic search.
The golang team has done a fantastic job. It is now my primary language of choice to get things done.
2 years ago I started playing with it moderately, and now in the past 12 months or so it has made its way into my normal workflow and have been delivering completed projects in golang.
I am excited for the next chapter in golang. Keep up the good work!
passion is more important, because if you have passion then your passion can take you from where you are now, to where you want to get to.
it takes time to become very skilled, even if you did excellent in cs. nothing is as good as experience.
so if you are passionate about it, keep at it. you won't get there tomorrow, but you'll know more than you did today. always try to re-evaluate what your doing and if most of the time it lines up with your passion, your doing better than a lot of people!