One thing that puzzles me about the Chromecast compared to other Google/Android devices - why has Google locked it down so much and not released a bootloader unlocker? Is it for publisher/DRM-type reasons (given that the Chromecast is primarily for playing content on your TV)?
These are my gripes with Unity, in question format :) Would love to hear from anyone that has concrete answers for these:
- How does UDK build apps for iOS natively on Windows without requiring a Mac? Are they doing some kind of insider thing that Unity can't replicate?
- I see Unity as massively extensible and that's one thing I like about it. Comparisons are often made between vanilla Unity and UDK; what about Unity + PlayMaker + UFrame + Level Builder, etc. I don't see this ease of editor extensibility with UE4 (I'm sure it's there; but the Unity Asset Store just lets me cherry-pick one, click buy and then just have it to use immediately after download - I like that).
- My biggest gripe with the editor is the font size. Will the new UI that's coming in 4.6 and/or 5.0 allow me to increase the font size used by the Unity editor to actually make it comfortably usable rather than fatiguing?
FWIW I've preordered Unity 5 and I use UE4 at the moment as well. Nothing big completed in either engine (just some side work here and there) but no fanboy-ism for any particular one (though a bit of a fondness for Unity as I encountered it back in the old Mac days when Unity were called Over The Edge Entertainment; GooBall was pretty cool by the way).
We'd tend to do that for stories, yes; take an overall story and assign it a number of story points. We'd then try and make time estimates for each of the story's subtasks, which is where I would have trouble. Time was a bit like a currency - "We have X number of hours available in this sprint, the sprint is big enough when we've 'spent' all those hours on estimates".
My experience actually matches what you're saying, in that there was always much better discussion around the number of story points and I never felt like my story point estimates were guesses. If there were any disagreements over story points, we'd at least be able to discuss it concretely ("here's why I think this task is more complex / more simple").
For what it's worth, before I was gone our process was moving more towards a velocity focus, where story points were getting more importance than time estimates. Generally Scrum was a new thing for our company and our group was one of the first to use it; I don't think they were using estimates as a whip, at least not intending to. However the business still needed/wanted concrete dates that the group had to commit to.
As many have said here, focus on what you're actually building. That means at some point you have to put aside the fear that the framework you've chosen "isn't good enough" and just build something with it. With any framework, there are going to be some things that fit well and more often than not some things that don't - I think it's rare that any one framework perfectly fits any one project, which is probably why so many frameworks are in existence in the first place.
So my ideal philosophy is to pick a technical stack and try something with it. Until you're building something with a stack, you're just messing around.
Now -- the harder to solve (and more infuriating problem) I see is a recruitment culture that seems to favor buzzword bingo. Why don't job ads just ask for "a developer who is comfortable having to work with or pick up the following frameworks quickly" instead of "MUST have at least 3-5 years experience in such-and-such. "
Don't even get me started on 'language quizzes'. Oh man I hate those. Learning language and framework minutae off by heart is pointless. In production code, it's rare to use ALL the features of a given language. So you have to be inquisitive, but at the same time turning down candidates because they know .NET 3.0 but not the minutae of .NET 4.5 is just lazy; unless the codebase actually uses the new feature (and then you have Google anyway).
(on that note, one of the best job ads I ever saw was for a games company where their only requirement was "show us a complete game you've built". Now THAT is sane and says to me that these guys/gals know how development works in the real world. Unfortunately I didn't have a complete game to send them, oh well. )
WRT to learning new things, I'm sort of going through that now. I'm "de-specializing" myself a bit by learning HTML, CSS and JS. I always pegged myself as 'not a web dev guy' but unfortunately the country I live in doesn't have the healthiest games industry. I had to drop the 'not that kind of developer' attitude and just go into it with as much of a blank slate as possible. It's been interesting so far, with the hardest mental roadblock I've had to overcome is thinking that "web pages are just documents" from my late-90s/early-2000s exposure to basic HTML/CSS.
I'd never made the connection between "low priority project" and "strictness of arbitrary deadlines" as the project having to continually race against its' own insignificance. That's a fascinating insight and raises a number of questions.
For example, 'crunch' is something that's endemic in the games industry and a contributing factor is that big publishers will impose arbitrary deadlines on their studios to 'ship a game'. So, what does this say about the significance of these projects? Also, are the deadlines really useless, or do they have some real basis? (EA is not going to go broke because a Need For Speed game is a few months late, for example).
On the other subject of programmers being bad at estimation. I've done a hell of a lot of introspection with regard to this and why I find estimates so unpleasant. A few reasons that come to mind:
- When you're asked for an estimate, what you're often really being asked for is a deadline.
- In a sprint planning session, I'd often get asked to produce an estimate for "how long will it take to design this?" followed by an estimate of "so how long will it take to implement?". Which makes no sense - I can't answer the second question without answering the first. This often came up with bug fixes or 'small' jobs - things that could reasonably be assumed to fall within a single sprint for at least some of the time.
- I feel like there's an unspoken rule that your estimates relative to other team members signal your competency to the team and to your manager. So if you're constantly providing estimates that are longer than those made by other team members, it's a bit like you're saying "I'm less capable than them". You feel encouraged to provide short estimates and then hide the difference. I see this come up most starkly when sprint planning wants consensus estimates, despite having team members of varying skill levels in the particular task being estimated.
- I find that 'watching the clock' breaks my flow. If I'm having to track my own time, it's like a bit of cognitive load that I don't want. I don't want to have to think about it, because losing your sense of time is so crucial to really being in-flow. Often tools will ask you to enter how many hours you worked on something as part of tracking. So you end up even guesstimating at that ("well it felt like I spent half a day working on it, so I'll put in 4 hours").
- As a result of the previous point, I don't really collect historical data that I can reflect on. It'd be great to be able to go back and see how long it actually took me to do stuff. Not to mention that when you leave a company, you generally lose access to any historical performance information like that which you may have built up over the years.
There is a lot about Scrum that I like, but as a whole I agree it still suffers from the arbitrary deadlines problem. I wonder if there's a business acceptable way that you could do sprint-like activity, eschewing the idea of time estimation and replacing it with effort estimation only. Rather than aggressively fixing the time through schedule, aggressively fix the scope of work and then just work towards completion "until it's done".
An important overall point that the article seems to be highlighting is that, in general (independent of these myths), developers are becoming less and less familiar with what the underlying system is doing. Or perhaps the more correct term is that developers are becoming more 'distant' -- there are more layers of abstraction in the whole system than there have been in the past. At the top, programming languages themselves want to get more abstract to make the process of writing software more efficient and in some ways more automated. At the bottom, hardware needs to use clever design to hide performance limitations that we come up against.
The problem is that sometimes, these abstractions leak. Knowing that what you're seeing is one of those leaks is key to not go down the rabbit hole of, for example, chasing a bug that ends up being caused by a hardware failure (painful experience!). So you have to keep notice of those layers below those you're directly working with; while you don't have to live there, you shouldn't totally ignore their existence.
I think this is a subtle but excellent point and answers the gut question I first had when reading your top post, which was to think: why would you (not YOU specifically, just the general 'you') marry someone who:
"....you don't respect, someone you think makes bad decisions, someone who isn't kind back, someone who is emotionally selfish or self-centered, etc. "
The answer being that you don't know these things going into it or they don't bother you that much; it's only when they accumulate over time that they start really bothering you. An analogy would be taking a new job at a company with lots of higher-up political BS - it doesn't bother you so much to begin with, but the more you learn the more it can do so.
EDIT: Realized I read your list of qualities as if you were talking about the same person with ALL those qualities in tandem; my "why would you marry?" obviously makes less sense if it's only one or two of those qualities in isolation.
Thanks everyone for the suggestions. I'm starting out by working through some stuff on TreeHouse and then will go from there. Looks like it's going to be a great adventure!
Why is WYSIWYG not used? Is it just that the available tools aren't good?
I would have thought that writing raw HTML would be a bit like writing raw WinForms code these days, or writing XAML by hand instead of using the forms designer.
Note that's the narrow application of visual editors I'm thinking of here - laying out buttons, binding events to buttons, binding data to elements, etc; not the "create a pretty looking page and have it spit out horrible HTML" type stuff.
Can you give some more examples of the kinds of closed-mindedness you're trying to get at? I'm trying to understand your line of thought. Are you saying that Myhrvold is being an asshole because he's elevating what he is doing to a much higher level than it justifies?
I realized after writing this that one force pushing prices down is that the marketplace has to serve a global audience; one thing lacking in the point of view of my question is that not every market in the world can afford to hire contractors at US rates and contractors on these sites don't just serve the US.
Alright this is the most awesome post I've read all day :) I really need to get to work putting together the kit Microbee that's currently sitting on my other desk....
Any specific recommendations for DeAngelo's later stuff?
I too was big into that whole PUA/game thing in a former life (more theory than practice though) and came to much the same realizations about it, particularly after listening to many of Barry Kirkey's radio shows (the very early ones) where he gave you the non-exaggerated, non-glorified view of what it was like to live in that house.
FWIW I also have a similar problem to the OP. Other things in life I'm sorting out right now but taking up classes again and going to meetups are on my radar for the near future.
I think a lot of it has to do with that 30% cut. 30% of a $25 app isn't that much, but I guess if I were someone big like Autodesk or Adobe and it were my big, multi-thousand dollar app, why would I want to give Apple a 30% cut when the distribution model that I have now works already? I guess that's why you see a lot of 'Lite' or 'Debut' edition apps, something to entice you over to the more expensive apps which can then be purchased without Apple taking a cut. There's no real benefit (and lots of downsides) as a developer if you don't need the Mac App Store for the exposure.
It's a shame that this stuff happens really; I think it relegates the Mac App Store to a certain niche more than anything else.
I was surprised at the limited selection I found in the store. Having just got a new Mac, I went searching for the usual suspects - no VMware or Parallels? I understand why as these apps can't be sandboxed. Hardly any commercial 3D authoring tools? Where's Illustrator and their ilk (not the Lite versions, the actual full versions). I was really surprised at the lack of big creative and high-end apps on the store - at least in the sense the big apps that the Mac is known for. It seems to be a bit of a wasteland in that regard. I'm sure there are many gems in the store from smaller developers, but I found the app discovery experience roughly on par with that of the iOS app store, which isn't a compliment :)
The convenience factor is wonderful though - it's been a few years since my last Mac and apps I purchased were right there waiting. Setting up the new machine was bliss. Hopefully many of these issues can be worked out as the store evolves.
Slightly off-topic; where do I go to find the gems on the store? What are the good review sites (something like what TouchArcade is for iOS games)? Any with a focus on creative apps?
I'm understanding and doing stuff now in my mid-thirties that my young self only wished he could do. To boot, I'm more excited and passionate about my craft than ever; certainly more excited than I was in my mid-twenties. I don't see this trend changing anytime soon.
Then again, I'm probably an old engineer at heart :) I love talking to those guys in their 50s that were programming COBOL or assembler before I was born. I was sitting in a career course thing recently and some of the older guys were sharing their experiences applying for jobs; all I could think was that I'd love to hire these guys if I had the means. Give me a wise engineer any day.
As someone in the job market right now, I'm refreshed by the article's admission of how much chance plays a role in whether you land a job.
I'm currently working on my CV and there's about as much conflicting advice as to what the 'ideal CV' is as there is about what the ideal diet is. It's somewhat frustrating but at the same time it just shows the amount of chance and variation involved in the whole process.
At least in the industry I'm going for (games / Unity3D for what it's worth), actions & side-projects seem to speak louder than words.
I tend to agree with you on this after having watched the first two episodes, but I'm keeping an open mind (I'm still keen to see what happens, so it hasn't lost me just yet).
The show just seems like this really weird combination where on the one hand it tries to be ultra-realistic (hey look here's a TED talk; here's something else mentioned in the netsphere! <insert other random SV/HN/tech cultural reference/buzzwords just because>) but then you have that stupid premise about the company inventing some kind of magically-impossible compression algorithm. Plus I think it was far too quick to show it's cards; BIG COMPANY vs LITTLE COMPANY?!?! REALLY WHO WOULD HAVE THOUGHT THAT?!?!
Maybe I don't get the humor either but I can't decide whether the show is actually trying to be a comedy or a drama. It definitely seems much more like a drama to me. I remember genuinely laughing more at parts of 'Pirates of Silicon Valley'.
Worked on a .NET app with lets of C# and C++ interop and we were seeing what looked like a rare race condition. The bug was hard to repro and never seemed to happen in our dev environment (like all great bugs!). The native code would just trigger access violations and we couldn't figure out what triggered it. We ended up getting extremely lucky and getting to a point where the bug started happening on my dev machine while I was running the app under a specific profiling tool.
It turned out we were racing the .NET garbage collector when passing a reference off to some native code. The variable being used by the native code would be collected by .NET as it determined that we no longer needed the variable when we were still actually using it. A classic .NET interop mistake that was fixed by wrapping the use in a 'using' clause. The reason we didn't see it while developing was that .NET garbage collection is different between Debug and Release builds (Debug builds extend the lifetimes of all variables so that they live for the entire length of the function they are used in; Release builds optimize for the shortest variable lifetime).
Another time, had a crash that seemed to occur after a consistent time period. The crash was in third-party code that we didn't have the source for. It 'kind of' behaved like a memory leak, except that everything was telling us the app's memory usage was normal.
After several weeks almost tearing my hair out over it, I ended up setting a breakpoint in the third-party lib using WinDbg and using PageHeap on the app while it was working in order to see who owned the memory that the third-party library was trying to write to. That lead us to a line of code that was performing a malloc() without checking the result; then sending that off to the third party library for use later. The malloc failed, neither us nor the third-party library checked for the NULL and the third-party lib wouldn't try to use the memory until later.
We eventually determined that we were seeing heap fragmentation causing the malloc to fail; we found that under certain conditions we'd leak small objects. Again WinDbg and other tools came in handy; they DID report high address space fragmentation, but it took us a long time to put the two things together. WHen we fixed the small object leak, the crash in the third-party library went away.
So classic bugs in hindsight, but they certainly taught us how awesome WinDbg can be (along with the other excellent debugging facilities provided by Windows). In the end, well worth the time investment in learning.