Ask HN: What skills would get me the best remote job? - <AUTHOR> So, due to family reasons I can't move from where I live (Ireland). The available jobs and salaries are incredibly poor here, I am struggling to make ends meet.
I feel I should try to aim for a remote job with a company that is willing to pay a much better salary (I am thinking $100k). I am a fairly competent web developer. Web developers are a dime a dozen, so I doubt if companies would really want to pay for a remote worker when they could easily get a handful just round the corner.
I am thinking I would need to become competent in a more niche area - an area that companies really need, but it is harder for companies to find recruits for. It would also be easier to become a leading expert in the field due to reduced competition.
Say I want to get this job in 1 years time, what skill sets would be the best to focus on - AI, networks, operating systems, compilers etc..? How should I best develop these skills? Presumably I will need to develop a decent portfolio to market my skills.. What would the best way to go around this be?
This is probably a fairly vague fingers in the air question, but any pointers or inspiration would be appreciated.. <comment><USER2> > Web developers are a dime a dozen, so I doubt if companies would really want > to pay for a remote worker when they could easily get a handful just round > the corner.

What exactly do you consider a web developer? If you're talking about the kind of web developer who codes a web page for his grandma's flower shop in html & css then I think you'd be right about that.

But if you're talking about one who writes backend code to scale, parse data and interact with external services or writes frontend code using whatever the latest javascript framework is these days, then those web developers definitely aren't "a dime a dozen". And they certainly won't have problems getting a remote job.

<comment><AUTHOR> Interesting. Yeah I'm definitely more the latter, I work on fairly complex financial saas type products..

<comment><USER3> Financial sector domain expertise in and of itself should make you stand out.

</comment></comment></comment><comment><USER4> Not sure if this will help, but this post was on HN yesterday. Skills to learn for standing out as a web developer: [http://fullbit.ca/learning-web- development-stand-out/](http://fullbit.ca/learning-web-development-stand-out/)

</comment><comment><USER5> As a remote Java developer of 5 years (10 years experience total) the remote market seems hottest for exactly your skillset,as others have suggested you'd be best levelling up your current skills.

If I wanted to get a remote job now the best combination of skills/techs in my opinion would be any combination of the following:

\- React/Vue.js/Angular

\- Node.js/PHP/Ruby

To stand out in the crowd I would do two things:

1\. Blog about the techs you use, it's a great way to get noticed when you apply for jobs. Posts can be as simple as you want around new things you are learning and is a positive chance to show off your writing and communication skills.

2\. Whatever tech stack you choose or are comfortable with you should have a demo application in Github/Bitbucket be it a React widget that pulls in data about the weather/stocks etc or if you are fully backend then a rest API or library to solve a particular tech problem. Focus on good commit messages, clean code and concise,descriptive and useful tests.

If you do get the chance to interview for a remote position then over communicate, remote work can be spread across countries and timezones and it's crucial to make sure information is available for everyone and understood to avoid blockers.

So if someone reaches out and suggests a time then I'd recommend messaging back with 'Great, I'm looking forward to meeting you. Just to confirm I'll be online at 4pm EST and my skype is XXX. Any problems feel free to reach out to me on email X or phone Y.'

Last but not least, you're not going to become an AI/network specialist in a year, you'd a competent developer (let's drop 'fairly'). Look at what you can improve in your current sphere:

\- Is your code clean and understandable?

\- Can you effectively explain technical concepts to folks that are not programmers?

\- Are your tests useful and effective?

Best of luck!

<comment><USER6> > If I wanted to get a remote job now the best combination of skills/techs in > my opinion would be any combination of the following...

I am a bit confused. What is the point of combining PHP with Ruby ? Isn't that an overlap ?

<comment><USER7> He means pick a combination with one selection from each front end and back end category. For instance you can pick vuejs from front end and combine it with php/laravel on the back end

<comment><USER5> Yup indeed, I wasn't super clear but that was my intention!

</comment></comment></comment></comment><comment><USER8> If you enjoy being a "fairly competent" web developer, why not work on that and become a "very skilled" web developer? You can make more than 100k that way, and the world needs a whole lot of web developers. If you aren't sure where to start, try picking some specific tools and contributing to the open source ecosystem. The world can still use cool new React libraries.

<comment><AUTHOR> Not sure I particularly enjoy being a web developer, it just seems to be where I have landed. I do love coding of all types though. There are definitely some open source libraries I am interested in though. I guess this leads to further questions, say I were to contribute heavily to a decent project, would this be sufficient to get a company's interest up (in your opinion) - or do you think it should just be one part of my strategy?

<comment><USER9> It's hard to say. Some employers will be pleased, impressed, and weigh in open-contributions. Others won't care in the slightest.

If nothing else I've found such things can come up in interviews, and be useful points of reference. It's better to say "Yes I've done XX, YY, ZZ and you can see examples in this project I published .." than to not have good examples.

</comment></comment></comment><comment><USER10> if your interest is getting the most money, it sounds like portfolio building could be a good use of time in the short-term. for instance... if your current portfolio is worth a 50k/yr remote job, and you improved your portfolio making ability (say, with a redesign or a retelling of your work history, etc...) for the next 4 weeks, and got a job offer for 75k/year... then you would have increased your take by 50% in 4 weeks.

if you don't think your current portfolio could/should be improved, then I would suggest that you look at the companies you're interested in working for and understand the sorts of work they need a remote developer for... and target that skillset.

alternatively, start your own thing on the side... do it for 2 years while doing a remote job that you can handle with 75% attention.

good luck.

</comment><comment><USER11> Look at remoteok and search the HN hiring post for remote roles. Review the skill sets listed, and work towards gaining those skills.

If you have those skills then work towards selling yourself better.

Believe in yourself!

</comment><comment><USER12> It's a supply vs demand thing. I doubt anyone is hiring remotely for AI and blockchain right now. Things like this are usually done face to face because they require a lot more communication.

Web skills are still in very high demand and still in low supply. JavaScript is used for TVs too. Java is used on a lot of systems. Few people go past the 1 year mark.

If you really want a niche, ironically, you might want to learn legacy systems, as they pay a lot but are very hard to recruit for. You can also learn a whole stack of systems, get certified with Google, AWS, Microsoft. I'd actually bet on Chinese systems as a fast growing market. So maybe look at Alibaba or Huawei systems.

In general, I recommend learning some low risk, low return skills and a few high risk, high return skills. The low risk skills will get you a job, the high risk skills will get you promoted.

<comment><USER13> I definitely don't agree with "learn legacy systems". There are high-paying jobs for those, but not remote (I've worked in a language that's in very high demand on the defense community but you need US citizenship AND security clearance to get those very high paying jobs).

</comment></comment><comment><USER14> You can try getting some freelancing work at [https://upwork.com](https://upwork.com) and then build a strong enough reputation or portfolio to take your business elsewhere (like your own website. Just use [https://www.thinkmain.com](https://www.thinkmain.com) to set it up and you're good to go.)

The goal with it would be to move to your own website eventually. Upwork fee's are around 20% from what I hear.

</comment><comment><USER15> Define fairly competent - Is it 4-5 years of experience on production scale system with great traits like commenting, documenting, automated testing and owning code? Or is it something closer to 2-3 years of experience, worked for a company didn't own much code? Market is hot at the moment for the former.

My company is hiring a remote web developer - if you're interested. Salary goes between 80-100k depending on experience. Contact is in my profile.

</comment><comment><USER16> It depends on where your skills already lie. If you do front end work you should learn one of the big frameworks. Love them or hate them, they're here to stay. You should check out some of the remote jobs boards and see what people are asking for. You may as well start applying now instead of waiting for a year, at the very least you'll get a more in-depth knowledge of what people are looking for.

</comment><comment><USER17> I'm a developer myself, and the skill that has been the most beneficial to me by far has been the ability to make decisions.</comment>


BIOS Bug – Passwords for Asus, Acer and Sony - <AUTHOR> http://biosbug.com/ <comment><USER2> Unsurprisingly the progress bar after submitting challenge text is ...fake :) makes whole website look shady AF.

Why use shady SaaS website that starts with deception when you could read open sourced reverse engineered recovery algorithms authored by dogbert here [http://dogber1.blogspot.com/2009/05/table-of-reverse- enginee...](http://dogber1.blogspot.com/2009/05/table-of-reverse-engineered- bios.html)

<comment><USER3> Or just remove the CMOS battery.

<comment><USER2> That worked up to mid nineties.</comment></comment></comment>


Netflix profiles, why now? - <AUTHOR> http://dangoldin.com/2013/08/14/netflix-profiles-why-now/

<comment><USER2> While I'm glad they finally implemented Netflix profiles, my account is jumbled with all sorts of stuff watched by people in my household and there is no way to reassign those views (as far as I know) under the new appropriate accounts. This makes my profile a jumble mess.

The only alternative is to start a new profile for myself as well and abandon the primary account and start fresh for everyone to ensure recommendations are all proper.

<comment><AUTHOR> Yea - they didn't quite think it through but I can't imagine the work to let people fix their history to be too big of a problem. Especially if they limit it to web interface only.</comment></comment>


Inside Facebook by Karel Baloun - <AUTHOR> http://www.fbbook.com/promo/mashable/read.php <comment><USER2> Good book, unfortunately the mashable URL only gives you free access for the next ~30 hours.

Positive karma for the first person who creates a script to scrape this, and then put it up on scribd... ;)

</comment><comment><USER3> get the book:

require 'open-uri';(1..48).to_a.each{|x| open('<http://www.fbbook.com/promo/mashable/read.php?p='+x.to_s){|u|> File.open("page_#{x}.html","w"){|f|f.puts u.readlines}}}

<comment><USER4> What is that? Perl? ;P

<comment><USER5> Looks like ruby.

wget -r can probably do the same thing and is easier.

</comment></comment></comment><comment><AUTHOR> Theres another url that gives permanent free access but I can't find the link currently :s</comment>


The Holy Fear - <AUTHOR> http://www.kellegous.com/j/2015/12/03/the-holy-fear/ <comment><USER2> The specific line that was cherry picked wasn't guidance, it was a warning to the Babylonians who held the Jews captive and committed atrocities against them that the Babylonians would have the same done to them.

<comment><USER3> Wait wait wait... you're saying this guy, who believes religious folks cherry- pick quotes from the bible out of context in order to support their preconceived beliefs, went ahead and cherry-picked quotes from the bible in order to support his preconceived beliefs about those very people?

That has gotta be the most meta thing I've ever heard...

Or maybe that's just hypocrisy. Potato potahto, I suppose.</comment></comment>


Scrap the $100 bill and make life tougher for criminals, Larry Summers says - <AUTHOR> http://money.cnn.com/2016/02/16/investing/hundred-dollar-bill-larry-summers/index.html <comment><USER2> I find this trend very disturbing. In Norway the largest bank has called for the outlawing of cash writ large. There have been similar statements by other bankers here in the US.

This all serves to give banks more control. Ability to impose negative interest rates without individuals hoarding cash, ability to greatly lower the risk of bank runs, etc.

But for the consumer and for privacy rights its a dangerous direction.

</comment><comment><USER3> Fine by me, if Larry Summers agrees to convert his liquid holdings into nickels, and never henceforth pay with anything but.

</comment><comment><USER4> Make them stronger, use only coinage....;)</comment>


South Korea Government wants to censor HTTPS traffics - <AUTHOR> https://translate.google.com/translate?sl=auto&tl=en&u=http%3A%2F%2Fwww.mcst.go.kr%2Fweb%2Fs_notice%2Fpress%2FpressView.jsp%3FpSeq%3D16672 <comment><USER2> The attachment details on the method of censorship: basically a DNS-based method for now, and will transition to an SNI-based method until 2019. Funnily though there had been multiple successful investigations dealing with the illegal copies of copyrighted works in South Korea. This particular censorship attempt is a result of the stronger demand from publishers to censor problematic websites as soon as possible---a bit of questionable development.

</comment><comment><USER3> As the main text is included in the HWP file of the original press release in Korean, here is Google Translate link of archived cached copy of Google:

[https://translate.google.com/translate?hl=ko&sl=ko&tl=en&u=h...](https://translate.google.com/translate?hl=ko&sl=ko&tl=en&u=https%3A%2F%2Fweb.archive.org%2Fweb%2F20180502063013%2Fhttp%3A%2F%2Fwebcache.googleusercontent.com%2Fsearch%3Fq%3Dcache%3AkrC8jFYUnxQJ%3Awww.korea.kr%2Fcommon%2Fdownload.do%253FfileId%253D185942541%2526tblKey%253DGMN%2B)</comment>


A Ridiculously large accurate scale model of the Solar System - <AUTHOR> http://joshworth.com/dev/pixelspace/pixelspace_solarsystem.html <comment><USER2> That's a web-based model. I was hoping it was going to be the Sweden Solar System. [http://www.amusingplanet.com/2011/10/world-largest-scale- mod...](http://www.amusingplanet.com/2011/10/world-largest-scale-model-of- solar.html) , at 1:20 million scale, with the Ericsson Globe arena in Stockholm (110m diameter) as the Sun.</comment>


There is no "my" in open source - <AUTHOR> https://medium.com/@nayafia/there-is-no-my-in-open-source-c3e5555390fa#.qd5bszg5t <comment><USER2> The right thing would be to remove the possibility of removing a package so that the registry doesn't break.

<comment><USER3> That's on the global level. On a local level, everybody happily depending on a third-party network service in their build process (even if it is just for setting the environment up) makes an idiocy.

Linux distributions have this problem solved for more than two decades: put all the dependencies in a source package and compile from there. But no, it's an old solution, and the one from sysadmins' world, so it's not sexy and can't be possibly a valid approach.</comment></comment>


Show HN: YouTube Playlists Done Right - <AUTHOR> https://diskyt.com/ <comment><USER2> It works! congratulations!

It feels a bit undecided on for whom it is, maybe even a bit like you are not 100% about this yourself. Throwing an a use-case or two would help.

Don't just show me what it does and how great it is at thet, show me my benefit.

If you focused on the Video more this could be: Remix your yt-channel: increases the views of existing videos and gives new viewers just the highlights.

Right now: Need to throw together the perfect mix for a party? Mix spontaneus or well planned from all of youtube, without advertisement interuptions and easy to share.

\---

Don't make me log-in before trying it out. Let me dive in to an example playlist right away. (you'd need to allow anonymous saves though or keep the state for after the registering somehow.

\---

The spinning image makes me think that each playlist is just one track. The player controls above the list don't help either, they should be in the right sidebar too.

There is also no visual distinction between folders and playlists.

\---

I didn't make an account yet, but you said you can set in and out-points per video? Maybe it would be easy for you to build a good mashup player (if buffering plays along) one should be able to mute on or use sound of one and video of the other. It's super fun and might be something that people are likely to share.

<comment><AUTHOR> Wow, so many ideas. Thanks a lot.

You are probably right, that it's not focused enough. I was making it mainly as a music player for my parents initially. So I tried to make it as simple as possible. Then, while playing with the site, I was adding features that looked useful to me.

I totally understand login dilemma (and the site already was blamed as suspicious/fishing on the YT forum). The funny thing is that initial version allowed anonymous editing, saving everything locally, but my kids told me that everyone is fine nowadays using their social login. Maybe I need to re- evaluate the assumption. But that will be a lot of work.

Mashup player, while sounds cool, it seems to deviate too far from the playlist handling and I'm not even sure that it's doable with the embedded YT player.

The spinning thing apparently does not even click with the young generation, they never used anything spinning really. Go figure.

Folders vs playlists. Well, former are rectangular, while latter are round - looks different to me.

So you are probably right and it's all over the map. I will wait a bit collecting feedback and fixing immediate problems and we'll see what could be the direction.

Thank you very much for the feedback.

Edit: trying to format properly.

</comment></comment><comment><USER3> I've always longed for a browser plugin that would let me use my browser history from a certain time window and save it as a playlist (use case - friends come over and DJ Youtube videos off your computer).

Maybe this will make it easier for me to recapture those nights.

<comment><AUTHOR> Interesting, I never tried to drag a YT link from my bookmarks, but it actually works. A link is just a link, and drag and drop does not care, where this link originates. Cool!

</comment></comment><comment><AUTHOR> And for a limited time you may have your new station featured: [https://diskyt.com/featured](https://diskyt.com/featured).

</comment><comment><USER4> good stuff, nice job! wish you the best.

<comment><AUTHOR> Thank you. It's rather depressing when you get zero feedback.

<comment><USER4> I understand that, we had the same feeling when we launch our side project a month ago.</comment></comment></comment>


Telegram F.A.Q. - <AUTHOR> http://telegram.org/faq <comment><USER2> Nice. A feature-complete, fast, open-protocol, open-source(partially at least), free-and-committed-to-remaining-free IM solution (iOS+Android mobile apps AND infrastructure) that seems reasonably secure, to a non-expert at least.

Have been looking for something like this ever since Google effectively killed Talk in favor of (half-baked) Hangouts, and, around the same time, cloud data security was widely demonstrated to be a contradiction in terms.

The question remains, given Telegram's architecture, to which extent does a user still need to trust the entity operating the server infrastructure. Harvesting of contacts probably remains a risk, etc. Any security experts care to comment?

More background: [http://core.telegram.org/api/end-to- end](http://core.telegram.org/api/end-to-end) [http://www.ewdn.com/2013/08/29/vkontakte-founder-launches- te...](http://www.ewdn.com/2013/08/29/vkontakte-founder-launches-telegram-a- new-instant-messenger-service/)</comment>


Kivy 1.9 – A framework for creating novel and performant user interfaces - <AUTHOR> https://groups.google.com/forum/#!topic/kivy-users/PZpI1g-W3do Announcement: https://groups.google.com/d/msg/kivy-users/PZpI1g-W3do/OZ84jGTlp4wJ Blog post: http://kivy.org/planet/2015/04/kivy-1-9%C2%A0released Downloads: http://kivy.org/#download <comment><USER2> There's a more extended writeup of some of the major changes/features at [http://kivy.org/planet/2015/04/kivy-1-9%C2%A0released/](http://kivy.org/planet/2015/04/kivy-1-9%C2%A0released/)

</comment><comment><USER3> Congrats, Kivy team!

I'd love to see reviews or performance benchmarks from people who've built using Kivy, but I can't seem to find much recent information. Can anyone help out? Thanks!

</comment><comment><USER4> are there any major apps written in Kivy and present on all the mobile platforms? or atleast on AppStore and Google Play?

<comment><USER5> I like kivy a lot, it is very powerful and promising. The following should not be taken as harsh criticism as it may look: Kivy has two problems in my opinion, why it isn't used more widely.

The first is the documentation, which while being quite extensive almost never tells the whole story, especially the many paradigms and details which are very different from other frameworks.

Second is how hard it is to even achieve simple tasks (beyond putting a few buttons together). A good example is the almost dysfunctionally complicated ListView, which actually can't do that much. Kivy's widgets in general are lacking, and the visual design philosophy seems to be "ugly by default".

This is really just my opinion. I think that the event and input handling is great, and the graphics library is very remarkable for supporting hardware acceleration to a python app on so many platforms.

<comment><USER6> > Kivy's widgets in general are lacking

That was certainly my impression just from looking through the docs. Unfortunately there aren't many people doing cross-platform UI well, especially for games. The few decent open-source options (eg, CEGUI) don't support mobile at all.

<comment><USER7> This is a pain point for me too. I have an idea for a game, and since I love Python I'd love to write it in Python. But the available Python libraries for game UI all seem pretty dire.

(Outside games there's more general-purpose libraries like PyQT, wxPython, etc., but they feel more suited for general line-of-business type applications than games. And besides, trying to mix them together with something like pygame turns out to be a world of suck unto itself.)

</comment></comment></comment></comment><comment><USER8> previously posted here: [https://news.ycombinator.com/item?id=9314238](https://news.ycombinator.com/item?id=9314238)

<comment><USER9> Posts with no discussion don't count as dupes on HN (there's too much randomness in what gets attention for that to be fair). But there have been others:

[https://news.ycombinator.com/item?id=8181306](https://news.ycombinator.com/item?id=8181306).

</comment></comment><comment><USER10> woot! congrats to everyone who contributed for a really big and important release!</comment>


Embracing ideas is how new things happen « Learning by Shipping - <AUTHOR> http://blog.learningbyshipping.com/2013/02/03/embracing-ideas-is-how-new-things-happen/#comments <comment><AUTHOR> To set the context, I think Steve's post is more or less triggered by the Snarky comments that David's article got - [http://www.wired.com/opinion/2013/02/the-end-of-the-web- comp...](http://www.wired.com/opinion/2013/02/the-end-of-the-web-computers- and-search-as-we-know-it/)</comment>


Don't be a Super Bowl loser  - <AUTHOR> http://successfulworkplace.com/2013/02/03/avoid-being-a-super-bowl-loser/

<comment><USER2> I love the Super Bowl ads: they have high production values, and often inform or remind me about things that might make my life better in some way. They enhance the experience for me! I wouldn't want to watch a game where everything is lifeless, gray, stripped of the money it takes to do it all artfully.

Edit: downvoting me without comment is not the same as answering me. In what way does my preference for advertising during the Super Bowl make me a _loser_? (That kind of put-down reminds me of high school, and not in a good way.)</comment>


2012 voting machine altering votes - [0:18] - <AUTHOR> http://www.reddit.com/r/politics/comments/12q6wu/2012_voting_machine_altering_votes/

<comment><USER2> Same video, very few comments or upvotes yet:

<http://news.ycombinator.com/item?id=4748783>

<http://news.ycombinator.com/item?id=4748903>

</comment><comment><USER2> In case you're interested, the discussion has ended up here: <http://news.ycombinator.com/item?id=4749574></comment>


Why organizations should embrace randomness like ant colonies - <AUTHOR> http://blogs.hbr.org/2013/09/why-organizations-should-embra/

<comment><AUTHOR> Full disclosure: I helped edit Andrew Smart's book "Autopilot: The Art and Science of Doing Nothing" and I also made the text adventure for it:

[http://www.orbooks.com/wp- content/uploads/autopilot/autopilo...](http://www.orbooks.com/wp- content/uploads/autopilot/autopilot.html)</comment>


The Smartest Person Project - <AUTHOR> So there we were, having dinner, embroiled in conversation. "Who is the smartest person you know?", he asks. After an indepth conversation about intelligence and the different meanings of the word, we wondered: "What would happen if we asked everyone we knew to identify the smartest person they know, then asked the next set of people and so-on...."? Well - that is what we are doing: www.thesmartestpersonproject.com <comment><USER2> The problem with how you've set this up is that you are not taking into account if the user personally knows the person you are asking them to recommend. Without that qualifier, you are likely to get a popularity contest and not an actual index of more accurate judgements.

<comment><AUTHOR> Thats a great point, and we did think of that. My hypothesis is that there are more people out there who will actually take it seriously than not. Thanks for your POV - I appreciate it.

</comment></comment><comment><USER3> I'd prefer some sort of quicksort to a bubble sort. Maybe a merge sort, for the amusement of shuffling people.

<comment><AUTHOR> I have all kinds of reports set up and ready to roll - Im working on a "results so far" view so we can see what is happening along the way.

</comment></comment><comment><USER4> Great Idea. I participated in it just for fun sake and I have to wait for it for too long. Even thats ok, but what's this:

"depending on the amount of money that we spend on this project, we may sell the results to recoup any costs. However, if we can avoid it, we will. Expect no more than $5."

</comment><comment><USER5> Great idea.

But why do you need to know the color of my navel for me to sign up?

In this case adding facebook/google/twitter connect is probably the best way forward.</comment>


Frustrated.js - Discover and react to frustrated users with 1 line of javascript - <AUTHOR> https://github.com/Isisawen/Frustrated.js

<comment><USER2> Awesome I'll be using it

</comment><comment><USER3> nice - this seems pretty useful</comment>


Ask HN: App in review for a month, no contact from Apple...what to do? - <AUTHOR>

I submitted an App to the App Store on May 24th. It went "in review" May 31st. It's has been sitting "in review" since then. The issue, apart from no decision being made, is that there has been absolutely no contact from the Apple review team whatsoever.
I've opened about 10 support tickets with Apple, asked for a "status check" from the review team about 8 times and had numerous conversation with the tech support team. Problem is that the tech support team and the Apple Review Team are two separate entities. Tech support has been great (in telling me that there's not much they can do, but at least they answer the phone or a ticket) but the review team has said absolutely nothing to me, despite the numerous requests.
It's been a month now of just sitting and waiting. Tech team tells me there's nothing they can do, app review team won't get back to me and I'm getting pretty frustrated by the lack of communication...
Is there anything I can do? Has anyone had this issue before?
Help, advice...anything at this point is appreciated before I lose my mind.
Thanks. <comment><USER2> It's just that time of the year.

Apple's Review Team are probably bombarded with a lot more applications than usual because of the Retina Macbook Pro and iOS6 support.

The average wait time is 3-4 weeks, and it's just nearly been 4 weeks, so at best you might have to wait up to 2 more weeks. I wouldn't be worried unless it's been a couple of months.

<comment><AUTHOR> seriously?... that seems a bit extreme

Thats not the impression I got from the tech team who have told me I've gone past the average wait time.

I wish these things are communicated better...and a month and a half to release an app is pretty ridiculous.</comment></comment>


Stanford Fall 2011 - Introduction to Databases - <AUTHOR> http://www.db-class.org/ <comment><USER2> It's not only Databases but Machine Learning and AI as well. I'm really looking forward to these Stanford classes and hope to take them successfully while doing my actual studies.

Direct links:

\- Databases: <http://www.db-class.org/>

\- Machine Learning: <http://www.ml-class.org/>

\- Artificial Intelligence: <http://www.ai-class.com/>

<comment><USER3> Thanks for posting the other two course. I can't wait till October. The Machine Learning course has a great a playlist on youtube as well.

[http://www.youtube.com/watch?v=UzxYlbK2c7E&playnext=1...](http://www.youtube.com/watch?v=UzxYlbK2c7E&playnext=1&list=PLA89DCFA6ADACE599)

</comment></comment><comment><USER4> This was one of my favorite CS classes I took at Stanford. It will do a great job teaching you the theory behind dbs then bridge that theory with real-world examples. If you want to get an idea about how databases operate behind the scenes AND how they should be properly used, this is a great class for you.

The relational algebra sections of the course are intriguing because it forces you to solve problems using a set of constraints that aren't present in other programming languages—really interesting stuff.

More information is at the class website <http://infolab.stanford.edu/~widom/cs145/index.html>

</comment><comment><USER5> Can anyone offer some advice in choosing between the three courses?

My background: I've only completed CS 1, and read LPTHW and Kochan's Objective-C book. I have about an hour's worth of Khan Academy videos in linear algebra, and have taken a basic prob/stats course. My university offers a database class, but not ML or AI. Based on my minimal knowledge of the subjects, ML/AI sound more interesting than databases.

<comment><USER6> You're more likely to need and use the DB course topics earlier in your career, unless you specifically get a job in ML or AI. However, those topics are also easier to learn and understand on your own without guidance. If you post your school's db course curriculum, we can help you compare it with the Stanford one. Initial instinct - go with the ai or ml course (or take a reduced course load this fall and take both, then see if you can get the Stanford completion certificate to transfer as credits to your school).

<comment><USER7> I did my PhD at Stanford and took all three classes. DB is a more fundamental class, and probably easier. AI and ML are both great but they are designed to be taken in sequence with AI first then ML (which is a sub-field of AI).

<comment><USER6> _> However, those topics are also easier to learn and understand on your own without guidance._

Yeah, by 'those topics' I meant the ones covered in the DB course, not the other two. Most aspiring programmers usually find relational theory and XML relatively easy to grok.

<comment><USER5> Thanks for your help! The syllabus for DB isn't up yet at my University, so I can't give more details [1]. But given that you say DB should be easier, and that I can take it at my school, I think I should take AI. Besides--I had the same gut feeling.

[1] writing this I now realize I could easily get last year's course, but I'm satisfied with my current decision

</comment></comment></comment></comment></comment><comment><USER8> MemSQL will be hosting office hours during the Winter for the class. If you'd like to attend, send an email to firstname.lastname@example.com.

<comment><USER9> That was a great way to make me google MemSQL. Are you guys affiliated with the course at all, or just being helpful and doing marketing at the same time?

</comment></comment><comment><USER10> Do I have to attend the classes "live"? Or can I catch up according to my schedule, as long as I submit the assignments on time?

<comment><USER11> Does anyone know the answer to this?

Essentially, I'd like to know if i should continue waking up with the US East Coast or finally join the regular morning people in India.

</comment></comment><comment><USER12> The videos are already online if anybody would like to get a head start.

<http://infolab.stanford.edu/~widom/cs145/index.html> (Click on "OpenClassroom Videos")

</comment><comment><USER13> Now if only they had OS and Compilers :)

</comment><comment><USER14> anybody know if it's inappropriate to sign up to be able to watch the lectures and check out the homework, but not actually intend to submit all the assignments? it's not clear if the course materials will be accessible without being officially "enrolled". I want to check it out at my own pace but I can't guarantee I'll have the free time each week for the assignments.

<comment><USER15> There's no cost to failing, I assume. Sign up and don't do the work, you won't be the first student to ever do so.

</comment></comment><comment><USER16> Even though I usually scoff at pre-registration signup forms, I was very excited to fill this one in.

I'm sure there's a lesson to be learned about my own sampling bias and it might be time to rethink this stance (how ever hard it may be to recognise that people can actually find enjoyment in hearing about product launches and events!)

</comment><comment><USER17> All of these online Stanford classes seem very cool. I hope that enough people sign up for these that grading and certificates become more popular from all of the highly respected schools.

</comment><comment><USER18> A quick look through the syllabus shows that the last video is "NoSQL Systems". Nothing specific in the Course Materials though. Maybe an Intro to Databases class should talk a little more about other approaches such as document-oriented databases. I know they (academia) are sticking to classical CS, but maybe some parts of relational databases could be covered in a second class on databases, to make room for more exploration on other DB approaches in an intro class.

<comment><USER19> The video states that the course will be RDBMS-centric, but there will be forays into XML data.

</comment></comment><comment><USER20> I'd love to sign up for both this and the ml class (though, I think I will sign up for the ml class...).

However, I've already committed to the AI class, and in addition to my regular coursework (Entering second year of uni, go me!), I don't think I'll be able to handle this.

<comment><USER21> for what it's worth, if you take the ML class, you will learn most of the things you would learn in the AI class and more - although it does get a bit rigorous, and will take more time than the AI class would.

<comment><USER20> Thanks. I looked through the ML class stuff, and I'm sold. Really looking forward to it.

<comment><USER21> not sure if you saw it in the other thread, but you can check out <http://www.stanford.edu/class/cs229/materials.html> for some old course materials.

this is easily one of the best classes i've been able to take - as i said in the other thread, i was surprised to enjoy a 3-hour midterm! i think it's awesome they're making this available to more people.

</comment></comment></comment></comment><comment><USER22> I wonder how the assignments will work? Will they all be automated grading (based on some sort of validated output?) If the users gets to thousands, hand-grading is out of the question...

<comment><USER23> Assignments and exams in the public course will be similar to the Stanford ones and they will be scored automatically. 1:23 in on the intro video.

</comment></comment><comment><USER24> This is great- I'm taking Into to Databases and AI at my university this semester, and I'm sure working the Stanford courses alongside those will give me some awesome perspective.

</comment><comment><USER25> Anyone know if there are any prerequisites for the class? Would someone with programming knowledge but no database knowledge be able to take this class?

<comment><USER26> I just signed up and have some programming knowledge but practically no database knowledge. From reading the description and looking at the syllabus, I don't think any coding knowledge is required. I do think though that this is critical for learning to code because you're always going to be dealing with db's in some form or another, so I'm excited.

</comment></comment><comment><USER27> Any word on whether the course materials will be available in the future, or if the course itself will be offered in the future?

</comment><comment><USER28> Am I understanding correctly that this course is more about how to use databases than how they work and how to implement them?

<comment><USER29> This is the undergraduate DB class. You are probably looking for the graduate DB class: <http://infolab.stanford.edu/~widom/cs346/>

</comment></comment><comment><USER30> why aren't these on stanford.edu subdomains?

<comment><USER31> Maybe to emphasize that you are not getting credit?

</comment></comment><comment><USER32> How is one single teacher going to deal with thousands of students?

<comment><USER33> Why can't one single teacher deal with millions of students?

Or are you stuck on the system you grew up with, unable to imagine any improvements?

<comment><USER34> billions

</comment></comment></comment><comment><USER35> Winter just got interesting!</comment>


Founders: Mature But Don't Grow Up - <AUTHOR> http://betashop.com/post/5108538903/founders-mature-but-dont-grow-up

<comment><USER2> Well written. There are so many little things that serial entrepreneurs have learned that each successive company moves faster. The point about first-time entrepreneurs having trouble with the company side is true, and groups like YC are geared to assist in that aspect so the founder can focus on the product.

But take someone who is building a great product, and who has the experience for building the company around the product, and you've got a better combination than just a first-timer with a product.</comment>


How I (and you?) am hurting the PC industry - <AUTHOR> http://www.cringely.com/2015/08/14/how-i-and-you-am-hurting-the-pc-industry/ <comment><USER2> Cringely notes, as many others have noted, that there isn't a compelling reason to upgrade your PC. Without those sales the people who sell PCs have a hard time making a profit[1].

I have been in the middle of the microcomputer revolution from the start. As high school student when the Altair 8800 was released and an engineer during the second generation of IBM PC compatibles, and as an engineer and user during this third generation of utility computing. For most people who own a laptop today, and perhaps everyone who owns a laptop but does _not_ own a desktop machine, what we call computers are just a tool for them. Cringely falls into that category, he writes about computers and so has one, but he hasn't bothered to get anything since 2010 to replace it because, and this is the key here, things that are popular as "computers" today (Raspberry Pi's Arduinos and what not) are not all that useful as "writing tools" relative to what his 2010 Macbook provides.

So generation 4, computers eat the rest of the workbench, is where the action is today. Software defined radio has replaced a crap ton of parts with a single platform. People build timers and pre-amps and automatic sprinkler systems out of chips with ridiculously over powered CPUs for what they are being asked to do. So we see this interesting fork with "general purpose" computing being a server somewhere on the other side of a network, "utility computing" being a dedicated UX device (Chromebook as an example), and "embedded computing" where the computer is a bolt on to some other function. But the old "PC" business that powered Comdex in the 90's and early naughts? That is dead dead dead.

[1] So people like Apple sell a bunch of things which are computer tech in other form, phones, media players, tablets.

</comment><comment><USER3> I am of the opinion that the inability to upgrade newer MacBooks is the result of Apple chasing the slimmest, lightest and minimalist laptop it can. It's customers having to buy a new model every year or two is however a nice side effect.</comment>


Programming: Doing it more vs. doing it better - <AUTHOR> https://kevinmartinjose.com/2019/04/08/programming-doing-it-more-vs-doing-it-better/ <comment><USER3> Someone who's been programming for three years is still a beginner, even though based on what he wrote here, Kevin is almost certainly a lot better than I was when I'd been programming for only three years.

I do find that a lot of programming stuff that used to be hard is easier for me now that I've been progrmaming for 38 years. But that doesn't mean I spend all my time doing things I can do without thinking, and it certainly doesn't mean I write code that doesn't need refactoring. Maybe my designs are better than they used to be — I think so — but often that's because I developed the design _more_ incrementally through refactoring, rather than _less_ incrementally by planning.

I do avoid a lot of errors by thinking through the consequences of a choice before taking action, in a way that I couldn't always do. But often that choice is specifically the choice to plan out a big design at the start of a project.

Also, though, what counts as "big" has changed for me. What I can hack together in an afternoon now might have taken me a week ten or fifteen years ago. So I can explore alternatives with less risk, in a way.

The author describes a lot of anxiety and guilt about doing things imperfectly. I think that's a big obstacle to improvement — other people can pick up on that and will be reluctant to give you feedback, and feedback from other people is a really fast way to improve. Also, it tends to shunt you into tasks that don't challenge you enough — it pushes you to avoid risk, and pushes other people to not ask you to do things that are at the limit of your abilities. This is precisely the dynamic Atwood was trying to combat by telling his story.

<comment><USER4> Someone programming for 3 yrs is not a beginner, There are people programming at 3 yrs that are experts and will run circles around you and your 38 years. Some people really have the talent and put in the work to get good. In 2019, the mentorship is available via means of books, blogs, MOOC, youtube videos, conferences. What some folks can achieve in 3 yrs these days is really unbelievable. P/S, I have been hacking around the computer for 25yrs and think I'm a pretty good programmer too. But I have been impressed by some 2 yrs old & 3 yrs old experiences.

<comment><USER5> Interesting view. I'm learning, with about 8 months worth of knowledge and experience, and this is useful.

Did you notice any skills/traits in those people who were "unbelievable" in those 3 years? For instance, did they do "test driven development"? Also, did they keep good log habits?

<comment><USER6> I think OP has provided good context. But I will try to answer the question you _really_ seem to be asking: unfortunately there is no shortcut.

There are things you can do that will, like the author said, give you faster feedback and thus let you get better _if_ you use that feedback. You might write a lot of code and read a lot of code and internalize good patterns. Eventually you will have enough experience and the confidence that comes with it, to take on bigger and bigger challenges. I don't know what happens after that for I am still in that stage. But I have observed more experienced programmers and one thing they're very god at is _really reading_ others' code thoroughly and being able to spot better ways of doing things (which I imagine is through experience) and also thinking a little bit in the future rather than simply the assigned task. e.g. if assigned to create a new system, they won't just follow the design specs blindly, but will question the design choices rigorously, helping improve the design a lot, and then implement something a tiny bit better than the eventual design.

Maybe I'm making it a bigger deal than it is, but I've worked closely with senior engineers and it's _always_ a fascinating experience. They will question your design and code very very deeply but all of them will be good questions and will help you either improve your design or not add spurious code.

<comment><USER5> This is very helpful. Your points make me think of the need for immersing in the experience and intently considering not only the 'what' but also the 'why' of actions, as well as alternative approaches to solve problems.

It also makes me think of the importance of stepping back, questioning the scope of "design choices" available, and anticipating things other "than simply the assigned task", possibly for some long-term aim, as you write. This is neat, thanks.

</comment></comment></comment></comment></comment><comment><USER7> I think one word would shed light on such anecdotes: deliberate practice. Countless literature and researches have pointed out that simply doing more would not bring much improvement but find out what is missing and practice it to perfection then move to another weaknesses is the best way to achieve top performance, be it in sport, in music or other fields. Like someone who want to learn chess; simply plays a lot each and every day will improve his ELO slowly but it will stall after a while (say at the level of a club player) and he can almost certainly never attain the mastery. In opposite, someone who seeks guidance, study and practice to fix his weaknesses and perfect his technique will improve vastly more in the same amount of time. Effective practice and coaching is also the only difference between merely very good players and grand masters. I can't imagine why it should be different in the field of programming and software engineering. Someone who writes thousands sloppy games might have learned how to do them faster (and maybe better) but he still learned nothing more about complex systems or secure systems. Only with intense study and practice he can master such stuffs effectively.

The Talent Code of Coyle is a good book to start reading about deliberate practice.

<comment><USER8> Yes, exactly this. If you never really think about your coding seriously, and ponder where you should get better at and then do it - you'll never improve! Simply by acknowledging your own mistakes and how you could fix them in the future, let's you build up skill much better than just churning out code day in day out without giving it a second thought.

I've seen the both extremes, the programmers who are so serious about the style of the code that nothing really satisfies them (and consequently progress happens at snail's pace). Then I've seen those, who'll write the ugliest of hacks just to get the thing working and move on. I think there's a deliberate balance between the two, where you feel you're not wasting time on useless things but actually get something done, which you can then comfortably show to your peers without beginning to blush.

And only way of getting there is practise and being mindful of what you are doing. Similar to sports, music - whatever. To know where and how you did wrong is key, often you'll need a very good teacher to show you that. Criticizing yourself works too, but often you either become too strict to yourself or too lenient.

Just starting to code without worrying if this is the "best practise" or not will allow you get into a flow which is much better than over-thinking your approach. Because once you start to do it, like a good warm-up it allows you to see the problem much clearer as you become aware of the problems as you encounter them. Then if you have time, you might want to refactor your solution or just move on the next most important thing. Sometimes it's better to just write awful code to get to that MVP or other important milestone, only after which you start to review your code. Experience will tell you, when is the right time to move fast and when it's good to slow down and enforce a particular paradigm to your codebase.

</comment></comment><comment><USER9> I've been coding intensively for more than half of my life from a young age - I'm approaching 16 years of experience now. Also, I've been doing it quite intensively (I was writing games when I was still in school before studying software engineering at university, then I worked for 14 different companies; some startups and some corporations in about 10 different industries. I've completed projects in at least 7 different programming languages). Also I've always been working on a side project during nights and weekends; mostly open source.

I have mixed feelings about the ceramics anecdote because I've met some people who have been coding a long time and producing large quanities of code but it's not good quality. To write high quality code, you need to enjoy the process and be adaptable. You need to have been exposed to a lot of different kinds of projects and management cultures.

Also, the most frustrating thing is that other people who are not good coders don't recognize straight away who is a good coder. Often, it takes a whole year to prove yourself. However, good coders usually know straight away who a good coder is.

Because of this effect, our industry is currently in a bad state. Many of the big popular tech stacks are mediocre compared to some of the alternatives that are available. There is a lot of misinformation and misplaced hype.

Most people who have the power to make hiring decisions are not sufficiently good at coding to be making those decisions. So good coders tend to find themselves smothered in most work environments...

<comment><USER10> Can you elaborate on your opinions about frameworks? What are some tech stacks that are mediocre, and why are they mediocre? What makes an alternative better?

</comment></comment><comment><USER11> Please stop thinking there are 10x programmers - or perhaps stop thinking it means 10x _better_.

It is simply 10x more _valuable_. And that depends on the organisation you work for, the state of the code base and so on.

Look at it this way - sports stars are regularly 10x, 100x more _valuable_ to their team management than A.N.Other professional player. Take football (soccer) - Ronaldo is a waaaay better player than I am easily 100x, but take the newest signing in league 3 or whatever it is - can Ronaldo run 10x as much, is he 10x as likely to put in a penalty or a free kick? No. it's probably not even a question of twice as likely - it's percentages better.

It's just that those percentages _matter_ when the cup is on the line. I am sure that Baseball statistics probably show this - the spread from top of the league to bottom is unlikely to be 10x more runs scored

So more and more it's worth remembering that the value provided to an organisation (and remember that's what you can charge for) is based not on your intrinsic qualities but what you can do for them in their current state.

<comment><USER12> Small percentages matter when the game is competitive. Programming is not competitive.

I agree with your argument but I think your analogy is bad.

<comment><USER13> How on earth is programming not competitive? Coming up with the wrong data model can result in millions of dollars in technical debt, a failure to fully realize a product, or certainly allow a competitor to win out. Bad programmers can structure a product so poorly that it is simply unpleasant to work on, and you won't be able to hire or retain engineers.

I think moreso than most careers, a single software engineer is capable of a tremendous amount of good or harm.

<comment><USER12> None of what you just described defines "competitive". A situation is competitive where one's gain is, another's loss. There's no such dynamic at play when programming, except _maybe_ career advancement in big organizations. When I write better code today than I did yesterday, you, my teammate, will be happier, not sadder.

<comment><USER14> All of the things mentioned are ways that bad programming can "allow a competitor to win out". Programming is competitive because markets are competitive.

Now, markets aren't always zero-sum. But they are often competitive.

 _> When I write better code today than I did yesterday, you, my teammate, will be happier, not sadder._

That's also true in football...

</comment></comment></comment></comment></comment><comment><USER15> > Three years later, I am still very much the apprentice.

Well, three years is really not a lot when it comes to developing an intuition. Just enough to grasp some basics.

> a writer is someone for whom writing is more difficult than it is for other > people

Yeah, I seem to recall Douglas Adams saying that the easier it is to read a text, the harder it was to write it.

At the beginning of my career I was constantly being praised for how fast I work. Well, I did stuff that worked, the effects were quickly visible, everyone was happy.

Even though there were code reviews to weed out the ugliest stuff, I wouldn't want to go back and maintain that software today :P

<comment><USER16> It might just be one of those universal truths: you need to understand something very well to explain how it works in simple terms.

Or as some smart person once said, "brevity is the soul of wit."

<comment><USER17> "If I had more time, I would have written a shorter letter" \- attributed to just about everyone: [https://quoteinvestigator.com/2012/04/28/shorter- letter/](https://quoteinvestigator.com/2012/04/28/shorter-letter/)

</comment></comment></comment><comment><USER18> I use one rule: If it's easy to remove, then it's fine.

Because only then, i don't fear refactoring later.

So i'll get my goal: Easy refactoring for fun and profit.

Refactoring is often underrated. Actually i learnt more from refactoring rather than "just make it work perfectly since day 1.

<comment><USER19> Most people talk about KISS, DRY, and YAGNI, but it's uncommon that I meet anyone who actually values _replaceability_. I don't even mind some repetition of code so long as groups of code aren't tightly-coupled and parts of an application can be easily replaced with rewritten versions.

I had a boss once who was dumbfounded that I actually _wanted_ to refactor code. I guess a lot of people want to write things "perfect" from the very start, but that perfection seems to be a delusion most of the time. The best way to know perfection is to see it in hindsight.

<comment><USER20> I usually state it as "Optimise Code for Deletion" \- the best code is code that can be removed completely because that means it can be rewritten cleanly.

<comment><USER19> I love that. :)

</comment></comment></comment></comment><comment><USER21> It's very easy: most coders are undisciplined hackers, not engineers. Unfortunately the prevalent macho coder culture (agile, and the rest of that crap along the lines of "move fast break things") positively encourages hacking away without much planning, design, or forethought.

Real engineers spend most of their time learning, thinking, designing, and planning. Coding for them is mostly exercise for fingers, something which needs to be done but ultimately providing no challenge. They learned not only from textbooks but also from their own mistakes, and know what to watch for and where to double-check themselves.

The outcomes are strikingly different: code produced by real engineers usually simply works. No need to babysit it in production. It also solves the real problem rather than "improving" on something which was adequate in the first place (face it: most new software replacing the older one is worse - <USER2> bloat, more bugs, harder to use). The real engineer understands that complexity is THE enemy, and breeding (or dragging in) unnecessary complexity is a hallmark of a freaking amateur.

Oh, and academia doesn't teach engineering. Your C.S. degree means shit. Old codgers who remember punching cards and incantations like //GO.SYSIN DD * may be tired of learning the shiny new toys and aren't up to the speed on the latest jargon, but over the years of wrangling code they acquired wisdom, and you'd be very well advised to listen to them.

<comment><USER22> I think labelling a development methodology and macho or not engineering is disingenuous. Any methodology practiced without an engineering mindset looks like that. Agile methodologies practiced by engineers looks like good engineering.

<comment><USER21> Methodology shmethodology. No management fad can replace thinking. Boeing 737 MAX is what you get when scrum masters get to boss around engineers.

</comment></comment></comment><comment><USER23> I've had this conversation a million times. I think when you're learning and working on your own to build a skill, do it fast and do it over and over. When you're working on a shared code base, you need to be more cognizant of your actions, of maintaining the established styles and conventions. I've know very few 10x or 100x programmers, and am not one myself. But I have had to deal with people who sacrificed quality for speed and every time a code review for those kind of people comes my way, I know I'm in for a ride that will take me away from the work I need to be doing.

</comment><comment><USER24> > Three years later, I am still very much the apprentice.

I used to think I'd get to the point where I could just sit down and breathe out perfect code, but that doesn't happen. As I've thought about the reasons why, I came up with the following reasons:

1\. Writing code is an act of inventing. If what I'm trying to build already existed, I could just go buy it and save myself a lot of time and money. It doesn't exist though. I'm being paid to create something new and unique. This requires thought, trial and error, and multiple iterations to get right.

2\. The software development landscape is not a static one. I used to build commercial buildings with my dad. Once I learned that studs should be set at 16" on center, how to measure and cut complex angles, and how to finish cement, I never had to learn those things again. They were pretty much static and I got to where I _could_ breathe out a plumbed wall without thinking about it. In the software industry, developers are constantly having to learn new things. New languages become popular, companies jump on things like Kubernetes because everyone else is, the JavaScript community cranks out new libraries and frameworks on almost a daily basis. While the fundamentals of recursion, looping, and conditionals remain the same, the syntax, idioms, and best practices are constantly shifting. After 30 years of programming, I don't think I'll ever stop being an apprentice in at least some aspects of my career.

<comment><USER25> Sometimes I wished I was a baker or a carpenter.

<comment><USER24> I do too, until payday.

</comment></comment></comment><comment><USER26> I do not believe the ceramics story. It is either nice fake to prove the point or what that particular teacher valued was a natural expression rather than perfection. Applying that principle to photography would mean that every one of us is now an artist because we made 1000s of vacation photos and photographers that used just film cameras are bound to produce lower quality work. I've also seen many startups that generated a lot of low-quality code that became a tech debt super fast, and all it needed is someone stopping the line and rethinking the whole thing.

</comment><comment><USER27> I suspect there may be better ways to practice, rather than just doing it more? Some people put effort into memorization of commonly used idioms.

Here's another dubious analogy: when learning music, you do need to practice, but playing a song all the way through a bunch of times is a rather inefficient way to practice it.

<comment><USER28> Other way of doing it more, is not just doing the same/similar thing again and again, but writing/reading large amount of very different programs. One day you do web app, other day you write a kernel driver, third day you write a scraping app, fourth day you write a tunel driver to get networking over USB, fifth day you reverse engineer some random piece of HW you have laying around and write alternative firmware for it to teach it new things, and so on. (it may not be days :))

Each of these things will branch out into different areas. You may need to write a text parser. You may need to design a USB protocol to relay packets. You may need to learn a processor architecture, calling convention, assembler mnemonics.

Over time you'll gain a lot of knowledge and you may be able to cross-apply plenty of it accross the domain boundaries.

</comment></comment><comment><USER29> I'm surprised the author didn't mention _learning_ about programming. Programming did come out of the field of computer science, after all.

Not that I think one should never do any hands on practice, but if you spend a large chunk of time learning the concepts of different mathematical fields related to programming, as well as the teaching of other programmers, you'll become a much better programmer than you ever could otherwise.

</comment><comment><USER30> I really disagree with this. There's a point on most projects where you've learned about all you're going to learn from it. Maybe it's still growing, but it might not be teaching you anything new. The best way to get good is diversity of experience, and the best way to get diversity of experience is to do a lot of different things. The more diversity you can pack into a smaller time space (without just cramming and rushing things), the faster you'll get good.

If you've only been programming 3 years, you're definitely going to make a lot of mistakes. That's good! That means you're pushing your boundaries and learning. Peer review feedback isn't a mark of shame; and being attached to your code is a _bad_ thing. At the end of the day, coders vastly overvalue code beauty and aesthetics, and overestimate how long their code is really going to live. (I've been a professional for about 11 years, and while I take pride in my work, a lot of the companies I worked for either folded, pivoted to a new product, replaced some of the things I wrote with open source solutions after the problem space had become less novel and a proprietary solution didn't make sense anymore, or a billion other reasons why the code didn't need to live anymore. I'm not saying that's an excuse to write shabby code, but a lot of times "it works and it solves the problem at hand and the code isn't a disaster" is when you should stop working on it).

I think coding is a lot more like creative writing than it is like engineering, and if you want to get good at creative writing you make a point of writing a lot of stories, even though a lot of them won't be good. Or if you're composing music, you write a lot of music, you don't focus on one piece forever. Anything where you make, the more you make, the quicker you get better at it.

</comment><comment><USER31> I think we're conflating learning and producing when we discuss quantity and quality. During learning time, quantity is what you want to focus on. During work mode, you want to slow down and think carefully. Only when you are very sure about the selected solution that you start going quickly. Applying the story of James Joyce in a broad stroke might be misguided.

If I have to pick, I'd err on the side of doing more than trying to slow down and write perfect code. When you're junior, your definition of "perfect" code might be very different from others'. You might be reinforcing bad habits rather than learning. I've seen junior SWEs insist on spending hours eliminating a couple lines of duplicated code by pulling them out into functions to achieve their perfect code. At the same time, they neglect basic coding hygiene, put defensive nullptr checks everywhere, and not design for readability and testing.

</comment><comment><USER32> The author has another blog post about learning to play the violin and how it taught him the importance of deliberate practice which I feel is probably what he is also trying to get across in this post.

I am experiencing something similar as I continue to study the classical guitar.

I agree that the importance of deliberate practice over just coding and coding really does matter - in my day job I will write many lines of code doing the same string processing etc. (I work in Data Science) but when I am trying to learn I really want to think if I am doing it in a Pythonic way, how I might make the code more reusable and so on.

</comment><comment><USER33> I spent my first 4 years after the university at a company with very little quality control. We had to talk the bosses into having code reviews. When we began having code reviews my older colleagues never complained about anything - everything went through.

That truly was quantity over quality. Oftentimes I had to wade through piece- of-shit code that really made my soul hurt. Really. Bad.

But in hindsight that was good. It's good to have spent 4 years ONLY writing code 8 hours straight 5 days a week.

But I never, ever, want to go back to anything like that.

<comment><USER34> This mirrors my experience. I spend the first two years of my career working somewhere where pretty much everything went through.

There were some projects in the company lead by developers that were some of the best I ever worked with. They upheld very high standards and the code was some of the best I've seen. Most projects were a total mess and nobody asked questions or reviewed code.

I worked on both type of projects. I think it really helped me. Some projects I just wrote code hours and hours on end without little regard to quality, but later on other projects within the company I was exposed to people and code that was significantly better.

</comment></comment><comment><USER35> >> The best writers write much more slowly than everyone else, and the better they are, the slower they write.

By that metric George R.R. Martin is on track to be the greatest writer of all the time :)

<comment><USER36> Nah. He just got distracted by the trappings of being famous.

<comment><USER35> No, he had written himself into a corner at the end of the "Dance of Dragons", and then waited for the tv show screenwriters to help him figure out how to proceed from there - that's the most probable explanation I can come up with (hinted by some statements from his interviews).

<comment><USER37> I think HBO just made it way easier. Once I heard the series would be a show, I knew we'd never get any more books because the lull between A Feast for Crows and Dance with Dragons was something like 5 years. At that rate, he'd need another 15 to be done while gallivanting on other fantasy titles/collections/anthologies/wtf and endorsing everything under the sun once the first three books gave him clout.

I'm definitely a little bitter about it, but I've accepted it. Parris needs the royalties.

/salt: Somehow, within that time, Robin Hobb managed to spit out a trilogy seemingly once a quarter. Thankfully, Steven Erikson came along and wrote The Malazan Book of the Fallen, which, if you like books, honestly puts ASoIaF to shame on numerous levels (and has the benefit of being done).

</comment></comment></comment></comment><comment><USER38> For me the best analogy is a carpenter tightening screws. When you start out solving a particular problem part of the scope and required functionality is always not 100% clear. So you start out with an implementation which favors flexibility over things such as DRY or performant. As you learn more about the problem you start to optimize.

One of the biggest mistakes (the biggest one is probably not writing tests) I see junior engineers make is trying to optimize before fully understanding the required functionality.

</comment><comment><USER39> I'm surprised the author's takeaway from the Joyce quote was disillusionment. He's actually quite close to the secret sauce. I don't think writing more code and ending up with less code are at odds. In fact, I think you need to write more code to end up with less. You write more code in order to understand the problem space. Once you understand the problem space, you can then refactor everything that you wrote into more concise code that more accurately reflects the problem.

James Joyce wrote Ulysses at the rate of a hundred words per day if you only consider the finished product. However, I doubt every word that Joyce wrote ended up in Ulysses. I'm sure he did quite a lot of cutting and rewriting.

The takeaway from me from the two quoted stories was that quality and quantity are not at odds, but instead are the yin and yang of productivity. They reinforce each other. The more things you produce, the more patterns you are exposed to which in turn leads to higher quality since experience leads to efficiency, giving you more time to get things right.

</comment><comment><USER40> I think when you are starting some new concept, that you are learning as you go you need to just try to do your best of throwing stuff on the wall to get it to work, refactor a lot and keep grinding away. During this time you are building the "Big picture" of what it is.

Once you get a good enough big picture then you probably will start to realize where how to optimize the data and create better methods, but even there it still never stops, you now know the system, and can figure out what you need from the technology to construct a better platform.

The databases I've worked with for over 20 years have evolved as I have added more functionality, I have been able to identify where the priorities were as well as how to make it function more dynamically. I didn't really get the big picture for a decade as they were sill doing part of it analog and only requested (revealed to me) more functionality as the system grew more capable.

You may think you know it all now, but I would think there's still a lot more road to be covered after only three years.

<comment><USER41> This was my first thought. I think beginners take better to volume but eventually we all hit a wall that takes more deliberate practice and deep reflection. Even then some concepts will be out of reach or take an exceptional teacher to break down. That doesn't even touch on the limits of individual abilities which we all face at some point.

</comment></comment><comment><USER42> As one of the million people who tried to read Ulysses and failed, I'm not sure I'd hold up Joyce as the example of what programmers should aspire to. There's plenty of popular and even good creative works which were written quickly or even under external time pressure.

</comment><comment><USER43> This article is good, but these conversations here on HN always bug me.

Yes—write a ton of code.[0] Just do it. Make your favourite couple languages extensions of yourself.

Yes—think through your code really clearly. Spend a day on your migration or other data-structure altering changes. They're going to echo throughout your whole application and, ultimately, organization.

[0] The closer you get to the API, the faster you should code. Not the interface definition itself, that should be thought through, but the code that responds to a call to the interface. The serializer, the part of the controller that calls the render, these parts are easy. Just roll them out. The models and migrations are much more important. Spend time there. It's not an all or nothing thing.

</comment><comment><USER44> I've been facing this in the past year after I started doubling my consulting rates. A part of me wanted to do 2x better work as well, and that just ended up in getting less work and lower quality work done.

Taking my sweet time is definitely not productive either.

I find the balance is to treat it like sketching. Instead of trying to "print" out code, well designed from scratch, from top to bottom. It's better to sketch out the main "lines" of it. It involves a lot of erasing past lines and old code, or even making redundant code at times. You definitely need a lot of scaffolding and placeholders, especially early on.

</comment><comment><USER45> This is why programming (as a profession) is engineering and is different computer science (as it is today -- when I was a student 40 years ago it was still turning into a "science"). Engineering as a discipline is at its heart balancing tradeoffs of factors like time, cost, weight, strength, efficiency etc. There is no single pole on any of these axes that can dominate, even though for illustrative purposes it's generally useful to do so when writing an essay.

(Also three years is a really short time, though the author seems to be using that time well in order to learn and meta-learn).

</comment><comment><USER46> > "Refactoring code" would be something left to the apprentice, not something > that I, the master who has churned out enough ceramic pots, would be > bothered with.

The master potter does not churn out pots that need to be fixed. He focuses on quantity to get to quality faster, that is the whole point of that story in my opinion.

Also, "refactoring code" should not be seen as such a separate activity that it can (or should) be done by other people.

</comment><comment><USER47> The point as applies to individuals extends to projects also:

 _> Programming system builders have also been exposed to this lesson, but it seems to have not yet been learned. Project after project designs a set of algorithms and then plunges into construction of customer-deliverable software on a schedule that demands delivery of the first thing built._

 _> [...] plan to throw one away; you will, anyhow._

Fred Brooks, The Mythical Man-Month (1975)

</comment><comment><USER48> People used to heavily criticise Minecraft from a technical point of view. Their criticisms were often entirely reasonable - it was at one point a very inefficient and unstable piece of software. However, it's now the second best- selling game of all time. Sometimes it's better to churn out a release and fix the problems later than let quality worries block you from achieving anything.

</comment><comment><USER49> Interesting. I've "evolved" in exactly the opposite way. I used to go for quality all the time. Nowadays I'm pretty confident getting things done swiftly (and thus enabling more code/design iterations) works better for me in both the short and the long term.

That being said, I definitely don't pretend to be the Thomas Mann of software engineering.

</comment><comment><USER50> Doing it more can provide better result _only_ when it is allowed to trash the previous iterations to use the latest one.

This is _not_ the case in the industry, we _cannot_ change everything in a product at each iteration. This is why at least a little care and architecture have to be done before doing it and trashing must be made with care.

</comment><comment><USER4> BTW, for anyone who wants to know more about the context, it's from the book "Art & Fear"

</comment><comment><USER51> This is why there are so many vulnerable products in the market and engineers are tired of fixing them. People do not think before they start and they are confident enough to say that they have learned from their faults when they are actually too tired to complete the fixing process.

</comment><comment><USER52> One prolific programmer who comes to mind from this article is Nikolay Kim, author of the Actix projects in Rust, aiohttp in Python, and many other open source projects. The Actix Project has evolved so much over a short period of time. The author learns by doing, with haste.

</comment><comment><USER53> Part of me feels like bootcamps are effective for some because you will inevitably start getting it when you do it for 15+ hours a day every day for an extended period of time (which is more than you'd likely do on the job or in a more theoretical CS degree)

<comment><USER54> >when you do it for 15+ hours a day every day for an extended period of time

Does this happen? I've programmed daily for ~11 hours/day between 2 companies, but at 15hrs/day I feel like there is diminishing returns.

<comment><USER55> Why 11hr/day?

</comment></comment></comment><comment><USER56> Write more, care about your craft in general terms. Then it'll get better. It's a skill, skills get better with more practice. Premature optimization is the root of all evil.

</comment><comment><USER57> I think that being a professional is exactly that:

"Being able to balance those two core things to meet client needs."

Any kind of extremisms is bad, no matter where applied.

</comment><comment><USER58> I have worked many times on ugly and on beautiful code. What I consider ugly is not always ugly for other developers and the other way around.

</comment><comment><USER59> FYI the ceramics story comes from a book called "Art and Fear" which I highly recommend to any creative individual.

</comment><comment><USER60> This is interesting reading. Continuous Delivery fits perfectly on this idea of continuous building and learning.

</comment><comment><USER61> For learning, produce as much as possible. For production, produce as little as possible.

</comment><comment><USER62> People who want to write "beautiful code" are not role models, don't listen to them. They are vain and not productive. Listen to the people who finish correct programs on time, or mostly working prototypes in hours or days.

How to recognise the former group: they obsess about coding and other standards and processes, plan and discuss too long how to implement something (plan _what_ to implement, do it, then improve it when it's done; inspiration comes from working on something, not from thinking about it) and never even meet their own estimates for how long it'll take them to deliver. They will tell you they are taking so long because they haven't decided yet how to best implement something, but they don't even have a straightforward implementation (there's always one). If they were truly concerned with "the best way", they'd have several solutions implemented already, together with metrics and benchmarks. They haven't, because they're vain impostors and not capable programmers.

<comment><USER63> I think it's a balance. At the other end of the spectrum are the "cowboys" who are productive by writing sloppy code with bad architecture and are either oblivious of or just ignore the huge pile of technical debt they pass along to the people who get to maintain their code.

<comment><USER62> Technical debt within a working codebase is a much, much better problem to have than not being able to launch or even demonstrate your product. It's really overrated. I left a huge pile of it in my previous company (amassed over 18 years of programming in Perl) and guess what: it's doing great, more profitable than ever before. The code has been slowly enhanced, some of it refactored. Code quality (as in "beauty", not correctness) is the least of your problems in a startup, although it will look bigger for those who have to work on it (pity them but don't overemphasize).

<comment><USER64> Yes, but the other side of the coin is having a codebase that is so old and such a mess that it can't be changed or upgraded without a tremendous cost.

I have worked for a company that eventually went down because there was absolutely no separation between business logic and user interface. When no one any longer wanted to pay for a system with an ASCII-interface (this was about 1995), they had to throw out about 5 million lines of code and never recovered.

I've worked with systems that had to be thrown out because no one any longer wanted to pay for a week of work for something should be possible in two hours.

Either extreme is stupid. Of course you have to ship. And in early stages it often makes sense to accrue debt to get fast to the market. But of course you also have to be able to be nimble and move fast even after two years and five. You can't do that if all your resources are tied up in interest payments.

<comment><USER62> > _When no one any longer wanted to pay for a system with an ASCII-interface > (this was about 1995), they had to throw out about 5 million lines of code > and never recovered._

Kinda obvious what their actual mistake was then...

> _I 've worked with systems that had to be thrown out because no one any > longer wanted to pay for a week of work for something should be possible in > two hours._

I see a pattern there.

> _But of course you also have to be able to be nimble and move fast even > after two years and five._

You can also go broke while chasing this illusion, twice. Whether as startup or established company with a "big ball of mud" codebase.

I'd rather tackle the "no one wants to pay" problem in a profitable company than a complete rewrite, or even trying to boot up a new company while, in addition to all the other problems involved, trying to write "beautiful code", thank you.

<comment><USER64> I don't know anything about you personally, but my experience with people that argue like you is that they don't understand or don't care about maintainable code at all. So every time someone tries to argue for something like best practices they get shouted down as completely unpractical and out of touch. The problem is that the people doing the shouting is often the ones that produces code at high speed. They are productive while everyone else has to clean up their mess.

Maybe I wasn't clear enough, but "no one wants to pay" and profitabitity just don't go along very often.

</comment></comment></comment></comment></comment></comment><comment><USER65> I think to second is good.

</comment><comment><USER65> I think second is good

</comment><comment><USER66> Programming is simple. Domains and interfaces are difficult. People over engineer stuff. People like to think they found the key to hidden wisdom. I believe I just summed up 90% of the difficulty with programming.

Just for the record procedural programming and functional programming are the only two styles of programming to me that make sense. Procedural because its how the machine model works and functional because its how a mathematical description of computation works. WTF is OOP (how the over active imagination of a child works I would reckon).

<comment><USER67> OOP attempts to map to real objects, (and sometimes not so real objects). I know it's hated by functional purists, but it really does make it easier to think through problems. I personally don't hate it.

<comment><USER66> Functional purists are the only one's who hate it. OOP by its very nature encourages developers to make bold abstractions prematurely (where prematurely is interchangeable with unnecessarily) and subjectively. Mean while the procedural programmer (Golang) has already finished the segment of the program having written one big function. If a piece of that big function is needed elsewhere she factors it out. Most of her program are simple loops and conditionals. Programs are easy. Programs are easy, why complicate something that is easy.

The machine should also guide the programmer as much as possible. I wish Golang had refinement types like Liquid Haskell or ATS. Some simple static analysis to cut down on crufty slow runtime test suites.

<comment><USER68> Nothing stops someone from waiting till they hit a pian point before refactoring during OOP. It's how I work.

But then again I mostly use Python and JavaScript which are multi paradigm so perhaps my mental model had evolved because of that.</comment></comment></comment></comment>


Currency.io, a html5 currency converter - open sourced to learn from - <AUTHOR> http://currency.io

<comment><USER2> It's not an HTML5 currency converter but an iPhone/iPod Touch currency converter. It doesn't work on iPad (and Android, and desktop browser, etc.). What are we supposed to learn from this? Bad practices? Arrogance?

<comment><AUTHOR> I'm pretty sure its clear what 'platforms' its built for on the site… but, some of the takeaway learnings are:

• HTML5 Application cache • localStorage • Developing a 'installable' web app for iOS • Yahoo YQL • Building a sintra app

<comment><USER3> _> I'm pretty sure its clear what 'platforms' its built for on the site_

I guess then you should change the HN post title.

</comment></comment></comment><comment><USER4> Ok, wait a minute. I always thought people preferred HTML5 over <insert platform specific API here> is that well, it's platform independent.

So I opened this app on my android phone... and nothing happened. Basically it said 'this (web) app is available for iOS only'.

Then what is the use of 'open web standards'? Am I missing something? Is this using a feature that android phones don't support yet?

<comment><AUTHOR> It was built as a tech demo and will work on iOS, Android and WebOS… but we built it primarily for iOS as a bit of an experiment to try to make something that "felt native".

¬ Of course you can fork it and mess around with it to make the experience better for android now too.

<comment><USER5> Why the iOS jail? I can think of plenty of cases where it'd be useful to have this, even on a desktop...

I know it may be 'designed' for iOS and mobile screen formats, but it seems to me a seriously bad decision not to have a 'show it to me anyway' button, along with a disclaimer that it (might) be broken on $platform...

And saying 'fork it' for an issue this trivial is not a great way to promote yourselves.

<comment><USER6> Technically it should work on Android (I believe we were testing against v2.2). What version are you running?

I think the main blocker with opening it up for desktop is having to design a more appropriate layout. Not impossible, just time-consuming. And as Ben says, it is intended as a tech demo.

<comment><USER7> It works for me on Android 2.2 on my HTC Desire (nicely, too!), but doesn't even pretend to work on any browser on my laptop.

</comment></comment></comment></comment></comment><comment><USER8> Looking at the CSS, I see you're styling the id tags. I'm not a designer, but my experience is that you should only style your ids sparingly and use classes for most stuff.

Also you have a bit of code to recreate some jquery functionality. Maybe for your purpose it's unnecessary to load all of jquery, but consider that if you use Google's CDN, there's a strong chance the user already has jquery cached. Look at the HTML5 Boilerplate for a snippet on how to use Google CDN and fallback to the hosted version. Again, might not be necessary for your limited use case.

<comment><AUTHOR> There are many schools of thought around using IDs vs Classes, some of the old was that "ID's are faster to parse", but really, its an old habit for many to use IDs. I think the answer is always "it depends", but I'm somewhat using classes and aria roles over IDs now anyway.

The "jquery functionality" you speak of is a query engine, but web kit based browsers have "querySelectorAll", which is native C code. jquery uses it (where available)… but being that we were trying to build something that downloaded very quickly on spotty 3g connections, we chose to write a couple of utility functions. (The total byte count for application.min.js is 3186).

</comment></comment><comment><USER9> In Firefox I see

\- a link to a video

\- a link to the source

Is the title misleading? "A html5 based iOS application to convert currencies" maybe?

</comment><comment><USER10> Its a gorgeous app and works well. The touch events feel a little laggy though (samsung galaxy s, android 2.3.4 / dolphin hd).

Also I would love to try it on the desktop, this would make a great widget. Any reason not to allow it to run on desktop browsers?

</comment><comment><USER11> While people argue over what things are and are not supported, I'm really happy you built this. I just got back from a 3 week holiday and it was disappointing that a lot of App Store apps require an active internet connection for EVERY calculation. Who can afford roaming internet when you're travelling abroad?

</comment><comment><USER12> Nice app, it would be nice to see the current exchange rate that it's using on the app to calculate

</comment><comment><USER13> Hate that I have to save it to my iphone desktop in order to use this ; not being able to try it out on my desktop was annoying as well, but I think enough people already expressed that sentiment. Other than that the app is ok, just not sure I'd necessarily want to spend much time learning from this source since it esssentially skips over what makes HTML5 cool in the first place.

</comment><comment><USER14> Really impressed with how much this feels like a native app! I've always maintained that web apps are the way forward and native apps will die.

Looking forward to checking out the code on GitHub and playing around with it.

</comment><comment><USER15> On the video you have an Indian Rupee as one of the options but in the actual webapp, it's not there. Instead I have South Korean Won. Is it because I have the korean keyboard installed?

</comment><comment><USER16> Hey ben, nice demo, regardless of it working or not on other platforms.

I'd be interested in your feedback on why you used binary images and avoided jQuery. I know the code makes notes on these, but were you actually already experiencing loading issues without using those techniques?

In other words, was it to practice using the techniques or were you already hitting visible loading delays each time you started the app?

Also, you mention using _em_ s for layout to handle resizing on the github info page, I've not heard of this technique, any chance you have a link explaining it?

<comment><USER6> Yea, we were hitting visible load issues on both the images and jQuery. Because the goal was to build something that felt like an iOS app, the longer the load screen was up, the less it felt like a real app.

The em technique is discussed in some detail here: <http://clagnut.com/blog/348/>

In practice what it also allows us to do is to set a font-size of 150% on the body and everything scales up proportionately.

</comment></comment><comment><USER17> Just curious, what software did you use to make the video? Thanks

<comment><AUTHOR> I think we used iShowU (available in the mac app store) and the iOS simulator that comes with the iPhone SDK/XCode.

</comment></comment><comment><USER18> Perfect domain name!

</comment><comment><USER19> This is great. Thank you.

</comment><comment><USER20> Why not just name it a "JavaScript currency converter"? HTML5 is such a buzzword to make it seem new or innovative.

<comment><USER21> Maybe because offline apps and localStorage started as a part of specification which later became HTML5?</comment></comment>


Ask HN: Why are we still not able to debug our bodies? - <AUTHOR> I mean like in real time, figuring out exactly what's happening with one's body, in order to diagnose problems, track nutrition, etc.
Why can't toilet do urine tests every day?
Why can't we ingest some capsule that tracks biomarkers in the blood, in real time?
This is so frustrating. We have all these awesome technologies, yet we have trouble diagnosing problems for what is maybe the most important thing for us - our body.
As a software engineer in my thirties with little knowledge in bio, I'm willing to devote my career into solving this problem. What should I do? <comment><USER2> Is very hard to implement the ideas. It's certainly doable, but mostly cost issues create an economic barrier. In some cases, it might not be scientifically feasible. Don't let that deter you though!</comment>