Invisible asymptotes - <AUTHOR> http://www.eugenewei.com/blog/2018/5/21/invisible-asymptotes <comment><USER3> >Shipping fees.

>People hate paying for shipping. They despise it. It may sound banal, even self-evident, but understanding that was, I'm convinced, so critical to much of how we unlocked growth at Amazon over the years.

>People don't just hate paying for shipping, they hate it to literally an irrational degree. We know this because our first attempt to address this was to show, in the shopping cart and checkout process,

"People hate shipping charges irrationally", because they perceive them as unfair additional tax that distorts price and makes it harder to compare prices. If price was including shipping/vat/taxes as single variable no one would be confused by it. Its not a magic asymptotic limit, its basic psychology: People want simple interfaces, simpler solutions, simpler interactions.

<comment><USER4> I just got back from Europe. I loved the way that the price of each object was exactly what I paid. The coffee for 2 euros? It actually cost 2 euros.

Now I am in the USA. I go to buy a large coffee for $2.79 and I end up paying $3.10. I hate this very much.

<comment><USER5> Well, when you hand over 2 euros that is inclusive of VAT (which if US resident you are not required to pay/entitled to rebate from the government) so the cost of a coffee is not really what's shown.

edit: all the downvotes.. want to reply instead?

<comment><USER4> I did not downvote you, but I can imagine people are down voting you because you seem to be making an effort to miss the point. The point is taxes are included in prices in Europe, but taxes are not included in prices in the USA.

</comment></comment></comment></comment><comment><USER6> This is a really interesting look into Amazon's business model around Prime, market segmentation in social media, and other things.

The author seems to have a deep understanding of how businesses work. Some of it's pretty gross -- I hate reading about "creating desire", and similar dystopic capitalist memes -- but it's important to _understand_ what's going on in these companies.

<comment><USER7> Why the distaste? I treat it as a study of phenomena. It's like a social study on rather grand scale. It doesn't different species much from the crowd dynamics, useful in better design of evacuation routes.

The application is not life-saving, but the conclusions are the same. It's like dynamite and atom splitting. You can use it for the good and for the bad.

> it's important to understand what's going on in these companies.

This is simple. They study people's behavior to drive it for their benefit. The basics of it should be taught in high school, so people better understand themselves.

<comment><USER6> The distaste is from people wanting to "drive demand", doing it, or recommending it. Driving demand is, quite literally, making possibly-happy people unhappy and then offering a paid solution. Reducing people's happiness for profit is basically evil.

And yeah, I'm _reading_ about it because it's important to understand, anthropologically.

<comment><USER8> Why the automatic assumption that the people were happy before, and that they won't be happier after? Have you never been happier/better off after buying something that you didn't know you wanted?

Driving demand is how some people discover lifelong hobbies.

<comment><USER6> No, generally when I buy something I didn't know I wanted, I soon feel vaguely "bleagh" about it and realize I had merely lusted after it, but that it didn't actually add anything to my life.

Buddhists have this down pat: Desire is suffering.

I think people are pretty capable of finding hobbies on their own. We're connected to this global information network. It's not like people aren't being exposed to new ideas all the time. But telling them "you will be happier if you buy this" is disingenuous, and makes people question their existing happiness. That's... bad.

I'll tell you one place where it's appropriate, though -- if someone is already seeking recreation, and doesn't know _which_ option they want, marketing a specific answer is fine. One of the reasons people love libraries is that they can go wander around and discover something they'd never heard of. But that's someone who is already looking for a book to spend time with! Compare to a banner ad saying "this book will fix your life", when someone was just trying to look up information on how to fix their mower. They don't need that. They need to fix their mower.

</comment></comment></comment></comment></comment><comment><USER9> > I'm almost invariably more interested in the folks who've registered > negative feedback, though I sense many product teams find watching that > material to be stomach-churning.

YES! I wish more people were comfortable dealing with negative feedback and not just receiving but also giving or soliciting it. IMO positive and negative feedback is complementary.

IMO, positive feedback is most useful for reinforcing patterns and trends - driving surplus by optimizing the current model. Negative feedback is most useful for generating alpha as it puts emphasis on where the real friction/desires are, what obstacles lie ahead and therefore what problem to solve instead of what is the best solution - allowing us to update our understanding, and break out of a cycle.

<comment><USER10> I feel the same way about feedback about my personal performance. It's always nice to hear "you are doing great", but at performance reviews or status meetings I really want to hear how I am screwing up and (more importantly) what I need to improve.

Having been on both sides of that conversation, it's really hard to deliver it, and takes humility to receive. But it's far more valuable.

<comment><USER11> I'm not saying you're wrong, but there is a difference between constructive feedback and merely negative feedback. Most of what I've seen is feedback with little understanding of the situation or empathy, and I think that is why people have become negative about receiving any sort of criticism. I had a boss that was great at that, and I always got constructive feedback, but those managers are far and few between. Most of the time I get things like, "The project is late." without any understanding as to how or why this happened.

<comment><USER10> > there is a difference between constructive feedback and merely negative > feedback

That's totally fair, and a great distinction. I will say that learning to ask for clarification on negative feedback is a good skill to have. Not easy when you depend on a job for income, for sure.

</comment></comment></comment></comment><comment><USER12> > Sometimes, the product-market fit with early adopters is only that. The > product won't go mainstream because other people don't want or need that > product.

This is something that SV has a problem with. Every product or company is assumed to be targeted at the whole world. There's no room for niche products. Either you take over the world or you end up shut down.

(Twitter is also notoriously bad at handling negative feedback)

<comment><USER13> Too true. If Vine wasn't popular enough to be kept alive, how the hell many users did it need?

</comment></comment><comment><USER14> This was a great read. I think the other unsaid takeaway here - touched on briefly when mentioning Twitter's glacial rate of product development - <USER2> that invisible asymptotes become insurmountable if your company has lost the ability to adapt and execute quickly by time you encounter them.

</comment><comment><USER15> I wonder if this shipping fees asymptote is the reason Amazon never shows me shipping rates until the last possible moment in the checkout process. That drives me crazy. They don't even show me if the item ships to my country until I try to pay for it... Arghhh

</comment><comment><USER16> > Seduction is a gift, and most people in technology vastly overestimate how > much of customer happiness is solvable by data-driven algorithms while > underestimating the ROI of seduction.

This is a bit unfair, but keen.

</comment><comment><USER17> I really identified with what he said about Twitter. It's a service that appeals to me, with my love of the firehose of information. Most people just don't want that - and that's fine.

</comment><comment><USER18> I know this is an Amazon PR piece but I need to point to their more recent aggressive behavior of growing revenue at the expense of user experience. My grips on their non refundable charges is a great example. Amazon will secretly renew your services without even emailing you and when you go to ask for a refund on a non agreed upon renewal, they will refuse to issue a refund.

I guess that's one way of overcoming these invisible asymptotes if all they plan to do is come up with creative ways to charge you.

<comment><USER19> >> Amazon will secretly renew your services without even emailing you and when you go to ask for a refund on a non agreed upon renewal, they will refuse to issue a refund.

I got charged by audible over 7 months, told them I wasn't ever interested, they send me 105$ back.

</comment></comment><comment><USER20> FYI: For those of you who enjoy articles like these, [https://stratechery.com/](https://stratechery.com/) might be worth your while ;)

</comment><comment><USER21> Some good stuff in here that risks being glossed over because of the length. Could use a tl;dr or a 75% reduction in words.

<comment><USER22> I thought the same. There's an invisble asymptote of the number of people who will read such a long text.

</comment></comment><comment><USER23> Great article, very long, so I scanned it.

It's interesting when it comes to Twitter, the argument seems to be that everyone who is gonna use it has come across it, its features are well-known, and there's not much to be done other than accept that.

Which got me to thinking about cryptocurrencies. This has now been in the news across the whole planet, everyone has read about it, maybe not everyone really gets the technical details, but probably the value prop of decentralized currency has reached a huge number of people now.

Or is it? What do you think?

<comment><USER24> The ideas are there, but the interface to get on board with cryptocurrencies are 10x as difficult than e.g. twitter - you have hundreds of currencies (or half a dozen mainstream ones), hundreds of exchanges for which you need to provide photo ID, various clients, loads of articles about security, etc.

Whereas Twitter is basically sign up and type a text message.</comment></comment>


TIL: Marissa Mayer Still Uses Gmail  - <AUTHOR> https://twitter.com/Yahoo/status/426795724542455808 <comment><USER2> Here is a screenshot of the tweet (cached version)

[http://i.imgur.com/N9z2ASR.png](http://i.imgur.com/N9z2ASR.png)

Title still doesn't make sense though.

</comment><comment><USER3> How did you learn that?

</comment><comment><USER4> page doesn't exist anymore.</comment>


Massive ongoing DDOS attack against most large bittorrent sites - <AUTHOR> https://twitter.com/P45C4L/status/431919299733635072/photo/1/large <comment><AUTHOR> KickassTorrents and EZTV, two of the most visited torrent sites on the Internet, have been down over the past few hours. The popular TV-torrent group is suffering from a DDoS attack, which may have hit Kickass.to and various other sites as well. [http://torrentfreak.com/kickasstorrents-eztv-suffer- downtime...](http://torrentfreak.com/kickasstorrents-eztv-suffer- downtime-140206/)</comment>


Hydra: A framework that simplifies development of complex applications - <AUTHOR> https://engineering.fb.com/open-source/hydra/ <comment><USER3> A framework that simplifies development of complex applications in Python. There, I fixed it.

<comment><USER4> Good point. The concepts of Hydra are not language specific though. At some point there might be something similar for other languages.

<comment><USER3> Indeed, the concepts are not language specific. I was hoping to see something with a grammar and a reference implementation. Looking briefly at this project, not all concepts can be abstracted but a specification with a set of integration tests would make it implementable in other languages.

Edit: it surprises me every time that a project like this always goes for a single language implementation. There are plenty of good concepts in there. I know purists will say "it does too much". But when one can crank out a complex cli app and spend half time on it thanks to things like this, I'm all up for it.

<comment><USER4> The project grew organically. Evolution was something like:

1\. Let's build a framework for model based RL, we can start by implementing the PETS paper ([https://arxiv.org/abs/1805.12114](https://arxiv.org/abs/1805.12114))

2\. It sure does have a lot of degrees of flexibility, and the PETS reference implementation is full of hard coded configuration. It would be nice to be able to combine configuration files somehow and override them from the command line.

3\. Looking around, I didn't find anything that was quiet what I was after so I created OmegaConf ([https://github.com/omry/omegaconf](https://github.com/omry/omegaconf))

4\. Building the framework, I evolved my understanding of what composing configuration actually means, and added additional features as I needed them.

5\. The MBRL framework became really nice and useful, but was still primarily an implementation of PETS. I tried to make it a bit more generic to allow others in my team to use it for other things, and realized the better thing to do is to go for something totally generic and make it a standalone package, Thus Hydra was born.

It evolved into what you see today, and it was almost exclusively my work - <USER2> at no point did I have the cycles to really support development in other languages.

One of the challenges is to convince people that it's useful, It can do many things as some people point out and people can get uneasy because of that. For Hydra to succeed, people should be using it, there is no point in spending years building something no one would use. ML, which is where Hydra grew from is dominated by Python today, That's why Python is the first implementation.

Building Hydra in another language is possible, especially now that there is a reference implementation, but it's a lot of work. If you are interested in trying it out I would be happy to discuss and advise.

<comment><USER3> Thank you for a thorough reply. It would be definitely an interesting exercise to port it to another language. I'll reach out. Let me do the homework, a deep dive so to speak, before reaching out.

</comment></comment></comment></comment></comment><comment> 52-6F-62 The name of this library almost feels a little too self-aware...

<comment><USER5> heil hydra o/

<comment><USER6> Given FaceBooks recent troubles, yeah, this seems a little tone deaf

</comment></comment></comment><comment><USER7> This is one giant antipattern. I hope people don't really use this.

It does too much. Configuration? Running apps remotely? This is a big cluster of miscellaneous helper tools glued into a ball called a library. I don't understand how it's useful.

<comment><USER8> It can be a good fit for quick throwaway projects, typically found in various research groups. Python itself is a giant antipattern for anything more ambitious I would say. Go provides far more rigor and stable foundations. Rust is also there for systems programming.

<comment><USER9> Make no mistake. In terms of abstractions.. rust is a higher level language then golang. You have more safety features of a higher level language in rust than you have in golang and you get it at zero cost. The exception is concurrency primitives which is golangs only saving grace.

</comment></comment></comment><comment><USER10> [https://cli.dev/docs/intro](https://cli.dev/docs/intro)

<comment><USER11> Code examples: [https://github.com/facebookresearch/hydra/tree/master/exampl...](https://github.com/facebookresearch/hydra/tree/master/examples)

</comment></comment><comment><USER12> So ... what does it do, exactly?

<comment><USER13> It looks like configuration management for devops. If I have an app and want it run in 3 different environments that each have rapidly changing configs, I might use this. But I won't b/c Facebook.

<comment><USER14> "But I won't b/c Facebook." Do I understand correctly that you also personally boycott React?

<comment><USER15> I do not boycott React because of Facebook. It's because its inferiority.

<comment><USER16> Inferiority to what? I hate Facebook as much as the next self respecting Netizen, but I still use React at work because it's just the best tool for the job. I'd be happy to hear some arguments to the contrary.

<comment><USER17> Ever looked at [https://svelte.dev](https://svelte.dev) ?

[https://youtu.be/gJ2P6hGwcgo?t=1055](https://youtu.be/gJ2P6hGwcgo?t=1055) [https://twitter.com/wolfr_2/status/1164621105476329472](https://twitter.com/wolfr_2/status/1164621105476329472)

</comment></comment></comment></comment></comment></comment><comment><USER18> I initially thought this was post for [https://github.com/ory/hydra](https://github.com/ory/hydra)

<comment><USER19> Or the Emacs library.

</comment></comment><comment><USER20> A genuine question. How come command line options are passed like so:

      python my_app.py db.driver=mysql db.user=omry

No intention to criticize. Just wondering if there is any reason you did not choose the more standard way:

      python my_app.py --db-driver=mysql

Wouldn't it be nice if all CLI applications could agree on a way to pass parameters? :S

<comment><USER4> Something like this could be implemented, but Hydra is using argparse for a few basic flags (--help, --run, --cfg etc) and argparse would not like us passing arbitrary undefined flags.

Philosophically speaking, I am not seeing a big advantage for Hydra overrides syntax to line up with getopt. What it does is different. For example, unlike with getopt - you MUST specify a value with every override, there is no support for flags like --verbose. it would have to be verbose=true, the reason is that those are editing the configuration object, and in 99% of the cases you want to put in a value and not default to true.

Also, you should be thinking of those command line arguments as editing a complex object. db.driver=mysql means: in the db map, change value of the driver key to mysql.

</comment></comment><comment><USER21> This is nice, especially the multi run. But it seems to be a boiled down version of click at first glance...

[https://click.palletsprojects.com/en/7.x/](https://click.palletsprojects.com/en/7.x/)

<comment><USER4> Click let's you build really nice command line libraries, but those are rigid and their structure is hard coded. A good example of what you wouldn't do with Click is logging configuration. You have a bunch of appenders, formatters and loggers and this is just not good with something like Click.

Hydra actually comes with built in Python logging configuration, it's just a part of the configuration object and Hydra is setting it up for the app: [https://cli.dev/docs/tutorial/logging](https://cli.dev/docs/tutorial/logging)

You can override this from the command line (unlikely but could be useful), or completely replace it with your own logging config: [https://cli.dev/docs/configure_hydra/logging](https://cli.dev/docs/configure_hydra/logging)

This kind of flexibility is a core part of how Hydra build the config, it's not limited to it's internal config (like logging) but extends naturally to the user config as well.

<comment><USER22> It might be nice if mlflow adopted something like this as a feature.

<comment><USER4> Tell them to take a look at Hydra.

Hydra has some overlap with what MLFlow is already doing, but I am sure MLFlow can benefit from configuration composition.

Another way to look at it is: What kind of Hydra plugins can be backed by MLFlow. for example, remote launching to any cloud can be implemented as a Hydra Launcher plugin. Currently the included launcher plugin is trivial (local execution), and the more interesting launchers to launch remotely are not open sourced as hey rely on internal FB infrastructure. Supporting the major cloud providers in Hydra through plugins is definitely something I would like to see.

</comment></comment></comment></comment><comment><USER23> Complex stuff to do supposedly complex stuff

</comment><comment><USER24> Looks hella useful to me, having developed plenty of python cli before this organizes in a way I've not really succeeded before.

<comment><USER4> Glad you like it!

</comment></comment><comment><USER25> This is pretty similar to openstack's oslo.config, but without the schema for the parameters. If you want validation, and ini rather than yaml, oslo.config may be your thing.

<comment><USER4> The config is the schema to some extent. see the section about strict mode here: [https://cli.dev/docs/tutorial/config_file#strict- mode](https://cli.dev/docs/tutorial/config_file#strict-mode)

At the moment it's not as rich as all of the other command line libraries in term of types, enums etc but it's richer what it you can easily express with it.

For example, I challenge you do express logging configuration with oslo.config, or Click, org argparse. You would be writing a whole lot of code to come up with something very rigid. With Hydra composing hierarchical configs is trivial so logging configuration is not harder than anything else.

What you would do with those other CLI libraries is just is either either hard code your logging config (eew) or separate it into a different config file and add logic to deal with it. In my book this logic is an example of boilerplate that Hydra can handle cleanly.

</comment></comment><comment><USER26> Java Spring!!

</comment><comment><USER9> Sounds like inheritance.

<comment><USER9> I mean how else can you 'compose' data? Either through overriding things (inheritance) or as a Product (ConfigA, ConfigB) (Also inheritance).

Technically you can do CoProduct (ConfigA | ConfigB) (not inheritance) but the logic of unraveling such a type is too much for configs so it's very unlikely Hydra does this.

<comment><USER4> It does, it's called configuration groups. [https://cli.dev/docs/tutorial/config_groups](https://cli.dev/docs/tutorial/config_groups)

(Assuming I understand your exact meaning).

<comment><USER9> I mean that there's only a couple of things it can be doing and inheritance is it... what else can it possibly be doing. I'm responding to a vote down.

<comment><USER4> I am actually not seeing "Hey, it's like inheritance!" as a vote down, although I am not normally reading HN so I may be naive.

<comment><USER9> I'm responding to my own comment because it's getting voted down, ha.</comment></comment></comment></comment></comment></comment>


Visual Computing Will Change Your Life - <AUTHOR> http://www.businessweek.com/print/technology/content/oct2008/tc2008103_228076.htm <comment><USER2> Totally unclear on whether it's the 3D imaging and information display (doubtful) or the calculation and modeling that drives those displays (likely) that's the real win. This article isn't very credible.

"Scroll the mouse and zoom out. Look at your inventory. Is all your problem due to one manager? Call that guy!" Well, you just described a problem that can be solved just as easily with an Excel spreadsheet.

</comment><comment><USER3> I think I saw this guy on a street corner yelling "the great visual computing era is upon us" through a traffic cone.</comment>


Ask HN: What are modern web-search engines missing? - <AUTHOR> I had my first computer (and Internet access) around the time Facebook and Twitter were starting to bloom while things like AOL were fading; at least around me. To give some context, these are my earliest memories of the Internet (which is actually quite a limited memory as far as the Internet goes).
Fast forward to 2020- I don't know if this is a mere nostalgic bias that lives in my head, but I feel search engines (SEs) are not doing well what a SE should be. My defintion of a SE being- finding the most relevant search results in the ocean of the web.
Is it only me who thinks that the WWW ocean has had dramatic shifts, but SEs are still stuck in time? I personally find it difficult to point what exactly modern SEs are missing; but I do feel there's something terribly missing. <comment><USER2> Talking about Google: what's missing is, things that used to work now don't work. Like "+", and verbatim searches don't always include every word. If you try to do more advanced searches, like using "intitle:" etc, after a few tries you have to do a Captcha each time. At least, I did last time I tried, a couple of years ago. (Thanks to using an old Mac + old browser, I never see any ads on google, but understand that's a problem for people too.)

</comment><comment><USER3> Contextual search.

For example if I search for a movie, then a bit later I search for a person, the SE should 'know' that the person I'm looking for is an actor in that movie and give me relevant results, not completely unrelated random people. That's beyond trivial to do.

Also removing all 'popular' results from link farms and pop culture sites, excluding entire categories for example searching for a mythological figure should give me results from *.edu sites, not weird ass anime sites etc (and Googles filters no longer work properly so you can't drill down in queries anymore.)

I think the market is ripe for a new product that does what Google used to do before they abandoned their core competency (and DDG is a joke and doesn't count)

</comment><comment><USER4> 1) API (to build search agents, complete tasks etc) 2) domain specific search 3) string match (I don't like semantic matching) 4) structured result with Facets

</comment><comment><USER5> Blacklist is certainly missing. I want to filter out garbage sites that somehow hacked the SEO game.

<comment><AUTHOR> Who should curate such a blacklist though?

<comment><USER5> I think it should be a blacklist I as a user can edit and contribute to.

Although if it's exportable, perhaps you can make importable list of blacklists curated by other people too.</comment></comment></comment>


I bought some stock options and they appreciated 3263.64% - <AUTHOR> https://medium.com/me/stats/post/87227c6b5562 <comment><USER2> On IOS Safari. Medium forces a login to see content.

It was only a matter of time. All those authors who used Medium as their Medium to share knowledge (face palm)

</comment><comment><USER3> Probably a penny stock that went from $0.01 to $0.32 and will plumb in a few hours ... Is this related to [https://news.ycombinator.com/item?id=18182155](https://news.ycombinator.com/item?id=18182155) ?</comment>


Going up? Space elevator could zoom astronauts into Earth's stratosphere - <AUTHOR> http://www.theguardian.com/science/2015/aug/17/space-elevator-thothx-tower

<comment><USER2> It's not the height that's the important thing. It's the speed. Even at 20km in the air, you'd still have to accelerate to roughly 7 miles a second, and that takes a lot of fuel.</comment>


How should I get started with programming? Which language should I learn first? - <AUTHOR> http://www.marco.org/3061580301 <comment><USER2> I completely agree that the most important thing is to have a concrete objective that you _really_ want to achieve that you are moving towards.

However, I disagree that every language is equally hard. There are three challenges in learning programming: syntax, logic, and resource management. Those can be optimized for beginners:

Syntax: A syntax that is more natural and less symbolic will be easier to learn. There is a lot to be said about brevity for experienced programmers. For new programmers, it is completely wrong.

Logic: While certain, highly mathematically-inclined people may be different, most people understand the concepts involved with imperative programming (I do this, then this, then this; if I do this thing a lot, I can abstract its concept; etc.). Functional programming, "pure" object oriented programming, etc., are concepts that add impedance.

Resource Management: Whether memory, pixels on the screen, or bytes to a network connection, you've got to interact with the hardware at some point. Different languages approach this in very different ways, from manage everything directly to nearly complete abstraction.

Trying to learn all three at once for any but the most highly motivated is a recipe for frustration and, ultimately, failure.

<comment><USER3> On the flip side, it really makes little sense to learn a language that is useless for what you want to do. If what you really want to do is program a microcontroller, it is my opinion that PHP or Python would be a very poor choice in first languages.

<comment><USER4> I agree that programming a micro-controller would make python a poor choice. That aside, I think its a great language.

I don't use it for months at a time. I proceed to forget everything. Shortly after, a need arises so I pick it back up. A week later, I'm a pro again.

The error output is what make it so amazing.

<comment><USER5> That is also why I prefer Python - I'm not a computer scientist, I am a business owner who uses programming as a tool to achieve my goals. Sometimes it's 2 weeks or more between writing code and Python is by far the best language that fits into my workflow.

</comment></comment></comment></comment><comment><USER6> I made the mistake of learning Visual Basic 6 first. That's like starting a race in last place.

<comment><USER7> While I feel your pain (and cringe on your behalf), I will say that many winners of NASCAR races started in last place.

<comment><USER8> I shudder to think of all programming languages being involved in an elaborate NASCAR race.

<comment><USER9> If programming languages were cars... <http://www.cs.caltech.edu/~mvanier/hacking/rants/cars.html>

</comment></comment></comment></comment><comment><USER10> To make it easier for a newbie: Choose Python if you want to learn programming for yourself - lean, lots of bindings for C-Frameworks, not much surprises and a big community.

<comment><USER3> (Presuming you want to learn programming _for it's own sake_ , rather than work towards some specific goal that requires code)

<comment><USER10> Absolutely true. If you have a certain task to do (programming a wordpress plugin, etc.) - the programming language chooses itself :) If you don't know yet, Python would be my best bet.

</comment></comment></comment><comment><USER11> My first language was QBasic i think, been through VB since then but i can't remember anything. I then began learning C/C++ which i still understand to this day but i keep a book close. Since then mostly Python and Ruby but really only Ruby since 2007 or so. I feel i have good understanding of code now at 22, still without CS education. I helped my friend with Java problems his second year in CS without having used Java past hello world, i know there are holes in my knowledge based on lack of experience but i feel i can read most languages without much trouble now. I think the main objective of learning to code should be to learn how to think as a programmer, learn how to understand code and really most importantly learn how to search the web.

Once you can master understanding programming syntax regardless of language, how to write good code and how to solve problems then you are well on your way to becoming a good developer.

</comment><comment><USER12> Probably some people would kill me for that answer but i would say you should learn PHP.

PHP is simple, good documentation and great community. Facebook is built on top of PHP so as Drupal and Wordpress.

But the main point about my recommendation is that PHP is installed everywhere, you don't have to spend much time configuring and doing sysadmin stuff to make it work.

<comment><USER4> So is Python!

I don't feel that a newbie should be learning a web language as his first. It just seems like an unintuitive learning process to me.

<comment><USER13> Ruby/Python don't have that same "click and drag into FTP client then load up in browser" ease, though.

I'd definitely recommend PHP to anyone who wants to jump into web development.

</comment></comment></comment><comment><USER14> It really depends on your goals and background I would say. At my school (education school) the point isn't to create students who can compete with computer science majors next door. Rather, we focus on getting students to 1) be able to understand the basics in order to communicate with more experienced developers and 2) quickly be able to create interactive visual programs for pilot research and the classroom. For us, the purpose is split between programming theory and folding in their learning and instructional theory into design. I used to teach Java which is great for focusing on OO concepts but the end products that students were able to create didn't necessarily match their visions. This discouraged a lot of students and turned them away from code. So sad!

Currently, we use Flash with a focus on OOP with ActionScript 3 (not timeline based loose junk). The advantage of this is that they can easily create rich assets in a simple and familiar environment to make the code part more genuine and purposeful for them. I've found that if you teach it this way they are very motivated to learn the programming concepts to realize their visions which are usually heavily tied to the visual and surface levels of a project. Gotta admit things you directly see are pretty sexy to many people. Once this "wow" moment is satisfied, it's much easier to point them in directions that go back to the programming theory to improve the depth of their work.

If you have a purpose and drive to want to accomplish something concrete you'll stick with the ups and downs so a programming language that supports that goal I think, is an appropriate language. It works well for us, the class is immensely popular and many of my students are very curious now of other languages like JavaScript, objective C, etc. The concepts transfer well too and some have even transitioned toward development. You can always learn new languages later although one commenter poses a good question of how one's starting language influences thinking. Don't have an answer for that one. But, my take is just try to get a good foundation with a language that supports what you want to do.

NOTE: I learned to program myself, and sought out specific programmers I admired to teach me so I don't have the experience of what a typical compsci program and curriculum is like. You might seek those opinions too. I would consider myself pretty darn good at understanding education and learning matters though so if you want any pointers, advice, or questions I'd be more than happy to discuss on this thread. I'm excited that you want to dive into programming. :-)

</comment><comment><USER15> I started wit Python. Still learning..

</comment><comment><USER16> Could always do it the academic way.... C, then C++, then Java, back to C++, back to Java. Once you graduated you will have learned no language mastery, just how to to think like a programmer... If that is what you want

<comment><USER17> Is this really the standard "academic way"?

At my school, CS classes started in C, did a touch of PHP/JS, then a functional language (was scheme, now OCaml), and then a giant hodgepodge of whatever you/the professor wanted.

<comment><USER18> We started with Scheme, then in the second year C++ and some Common Lisp. Later Smalltalk. You learned Java on your own, which is near trivial if you know C++ and Scheme.

</comment></comment></comment><comment><USER18> Classic question, classic answer. Buy SICP and learn Scheme. You probably will never build any "production" software with it, but you will learn a solid base for the rest of your carreer.

</comment><comment><USER19> Zed Shaw's "Learn Python the Hard Way" is a great way to start and test the waters - <http://learnpythonthehardway.org>

</comment><comment><USER20> Although I never learned Java, I would point you to that language. I would also suggest C# or Objective-C. Really anything with a gui or IDE will work just fine for beginners. Contrary to most folks, I view being able to write efficient and fast scripts with python in a plan-text editor quickly, as much more advanced than using something like microsoft visual studio to help code. Of course, I code this way so I have my biases :-D

</comment><comment><USER21> I started with Delphi in High school but moved to Python. In retrospect, starting with Delphi was a good thing, but using it for more than a year was a very bad thing! Now I'm into PHP, Java, C++ and other weird languages in addition to Python which is still my favorite

</comment><comment><USER22> If one is just dipping one's toes in the programming waters, then Delphi is a good start for native Windows development. It allows one to see positive results very quickly, which is important for beginners.

</comment><comment><USER23> I'm really curious about how the first language you learn influences your way of thinking about programming. I suspect that over the long term, it doesn't matter, but I wonder if it might make a big difference in the first few years.

For example, I started with BASIC, and then moved to C. Thinking in loops was really hard for me at first (as opposed to using goto).

What would be like if your first language was a Lisp?

Less seriously, what about Unlambda? Or Brainfuck?

<comment><USER24>
       (1) DO INTERCAL
           DO FORGET #1
           PLEASE GIVE UP

</comment></comment><comment><USER25> I'm going to break the rules here and answer _two_ languages.

First, you should learn one of the easy dynamic languages. This means Perl, PHP, Python, Ruby, Lua, Clojure. I think Ruby is a good choice because it has a lot of cool concepts built in to the core language that the others lack, and so it can be a foundation for learning many different styles of programming -- it does this, in my opinion, better than Python, and has a nicer syntax than Perl. _why's poignant guide to ruby is a bit outdated but still a pretty awesome and cool introduction.

<http://mislav.uniqpath.com/poignant-guide/>

Second, and this might come as a shock, some form of basic assembler. I recommend LC-3 assembler. And the main reason here is that a decent understanding of the memory model is going to help you a _lot_ when it comes to dealing with pointers, complex data structures, or anything, really. You'll probably never write a program longer than 100 lines in LC-3, but the short things you do write will give you a deeper understanding of your code everywhere else.

<http://en.wikipedia.org/wiki/LC-3>

[http://highered.mcgraw- hill.com/sites/0072467509/student_vie...](http://highered.mcgraw- hill.com/sites/0072467509/student_view0/lc-3_simulator.html)

There may actually be a newer "learning assembler"-styled language out there, but I am not aware of it. LC-3 is showing its age, but it was great when I learned to program, and I learned as much programming for three months in LC-3 as two years prior in Java.

That said, you should definitely familiarize yourself with control structures prior to jumping into assembler or you could break your brain.

<comment><USER2> Learning some assembly should be required for anybody who wants to make a career writing software and is very valuable for hobbyists. I don't know that I would start there, but at some point along the way, understanding what that nice, high level language is really doing down at the metal makes for much better engineers.</comment></comment>


"Careless" employees - <AUTHOR> http://niniane.blogspot.com/2013/11/careless-employees.html <comment><USER2> Systems, systems, systems. Spot on.

Just as in manufacturing, you cannot produce quality by blaming the individual worker. Japanese manufacturers learned this from W. Edwards Deming ([http://en.wikipedia.org/wiki/W._Edwards_Deming](http://en.wikipedia.org/wiki/W._Edwards_Deming)) and it continues to be true to this day, but for some reason the natural human instinct is to blame the individuals instead of the systems.

Improve your individuals and you can improve your quality maybe twofold, threefold at best. You might chance upon a "rockstar," but probably not.

Worse, _blame_ your individuals and you _lose_ productivity, lose trust, lose culture, instill fear, and break ties. Negative reinforcement brings unpredictable negative consequences.

Improve your systems, your culture, your process, your communication, and everything surrounding the production of your product, and you can improve your quality tenfold or more, and more importantly, be better prepared for a 100x or 1000x growth.

Blame your systems and they can only get better.

I can't think of a time when it's incorrect to think from a systems-first perspective.

<comment><USER3> I'm a huge fan of Deming, and many of the problems we see in software can be fixed by paying closer attention to his 14 principles.

One question that I've had applying him to software, though, is how you align his concepts on systemic defects (most defects are common causes) with the high variety of performance differences in programmers? In a factory or call center, the worker performance is uniform enough to view everything as a common cause, with the goal of reducing variation. In software, you want the opposite - you want to unleash your 10x performers.

I'm interested in your views on this. Again, I'm a huge fan of Deming and have read and applied his ideas throughout my career, but this is a sticking point.

<comment><USER2> This is like the Grand Unification Theory of Deming for me. I've been thinking about it for years.

This is a _classic_ question. It doesn't come up only in the software realm—in every company, there are always high performers, and there is always resistance to the idea of treating their output as systematic, or treating them in an individual focus, rewarding and seeking them out.

My thoughts are that fundamentally, the relative performance of your workers is irrelevant to Deming's prescription for quality. Your job is to improve the output of the system as a whole, and by no small coincidence, improving all your processes optimizes the company for all individual worker output the best. Continual improvement of _process,_ as it applies to the product, management, and worker alike, will result in higher gains than a focus on individual performance. This is the difference of kind—the Profound Knowledge Deming talked about.

If you think of it like that, it's more about human systems than it is about unleashing individual performance. Traditional management is about motivating the individual; Deming management is about recognizing that most of the output results from the system, and thus, improving the systems surrounding the individual.

The really fun part is how you look at performance. Firstly, you have to use statistics (after all, this is Deming we're talking about). Recognize that the performance of a group of humans is a sample, and as in most natural distributions it will resemble a bell curve. You will _always_ have outliers: mythical people who seem to outperform all others (most people focus all their attention on these). But _most_ of the group will be somewhere within 2 standard deviations of the average—AKA, normal. You will always have a handful of low-performers, too. This appears to match reality in my experience at several companies, as I'm sure it does for you.

Now, keep in mind that Deming _never_ talked about reducing variation in _people._ He talked about continual improvement, he talked about psychological effects of management on workers, he talked about enabling pride. His message was to _understand variation_ in the workforce, not to abolish it. Reducing variation is the goal for the output (as it should be in software also!), but not for the employee. He never applied those numerical style goals to workers at all, and in fact decried them as inhuman, and more importantly, ineffective. See Principle #10: "Eliminate slogans, exhortations, and targets for the work force asking for zero defects and new levels of productivity." In other words, recognize and understand statistical variation; don't demand a reduction in variation from individuals, improve the system to improve the output. Remember that: I'll come back to it.

To your second point, that software somehow does not have a "common cause" consistent enough to build upon. I also want to correct this a bit. Deming's first principle, "Create constancy of purpose toward improvement of product and service, with the aim to become competitive, stay in business and to provide jobs" applies to absolutely all companies imaginable. This constancy of purpose is not a constancy of performance or constancy of variability, but a shared knowledge and goal that everyone strives for. It's an abstract and unmeasurable concept. This was Deming's only foray into "common cause," though it was very important.

Back to the individual versus the system. Improve the system to improve the output. If ever there was a sentence to sum up Deming, that's it.

Yet you think you want to "unleash your 10x performers." That this is somehow the goal in Software, or in any company for that matter. _It 's not._ And here's why.

Your 10x performers are your outliers: the top end of the bell curve. The instinctual reaction when you get your hands on one or two is that you've gotta hire more people like this, and to reward and bonus and hold them up as pinnacles of achievement. After all, they perform better than everyone, they should be rewarded. And if we reward this kind of performance, we'll motivate other people to achieve more, right?

Wrong. This instinct is incorrect, and Deming based this (quite correct) conclusion on his extensive knowledge of psychology and sociology. Firstly, while you're focusing on one or two high performers, you lose the recognition that your output and your entire company is actually systematic. You might have 50 other programmers in the body of your bell curve, the lot of whom are still collectively producing 5x what your one 10x programmer supposedly outputs, and possibly more due to complex interrelated factors. Yet, by focusing on individual performance, you unintentionally demotivate the great majority of your employees, who are almost by statistical certainty "just average." The result of your efforts at improving and rewarding the performance of your 10x'er might be simply to keep them, or perhaps motivate them into being an 11x'er (big deal). You may motivate one or two people who happen to be motivated by money to improve their performance, but it probably won't last. The main outcome will be a slew of unintentional negative consequences throughout your company, including corporate politics, ladder- climbing, blame, mistrust, fear, and demotivation. Not good. (Side note: this is Corporate America in a nutshell, the result of a century of individually focused management. We've become complacent about it, sadly).

Deming would look at this in many ways. There would be laughter and enlightenment. There _has_ to be a paradigm shift.

First, look at the performance as a statistical anomaly. It will sometimes happen, quite by accident, that two programmers will have random variation in performance month-to-month or project-to-project. These are not unexpected occurrences. Sometimes the right state of mind aligns with the right motivation and personal circumstances to produce extraordinary performance. It has happened to all of us at times, surely. By looking at it this way, you get many realizations: that circumstances impact performance; that individual variation will occur naturally; that you might be rewarding an individual for performance which is an anomaly. This might sound like a small step, but in fact it's the root of many cultural problems and corporate politics, mistrust of management, power games, and infighting.

Second, how are you measuring performance? How do you determine 10x? Deming would scoff at the very idea. His 3rd "Deadly Disease" was "Evaluation by performance, merit rating, or annual review of performance." For similar reasons to the above, these imprecise methods cause more harm than good. They'll cause secrecy, fear, more infighting and game playing in an effort to reach the performance or review goal, instead of the true goal: quality work. Removing these false metrics reduces fear, improves culture, improves collaboration and allows people to be prideful of their work without ulterior motives. This unmeasurable metric is more important than it sounds.

Third, and most importantly, Deming would surely say: ignore the outliers. Focus on improving the system. Focus on the majority of your people, and the whole of your organization to improve quality of the final product. Implement improvements system-wide, remove rewards and quotas and individual expectations and replace them with leadership, training, continual improvement, and knowledge. Deming would tell you that most of the quality of your output is not tied to individual worker performance, but rather the systems of management, technology, and collective improvement that the company has implemented.

The point of this is to improve your entire organization: your average 50 "1x" programmers might double their performance, resulting in 50x more performance than hiring one holy grail 10x programmer, or unleashing your existing one. That is a simplistic way to think about it, however. The actual improvement is much greater. By focusing on the company as a whole, and focusing on the needs and performance of all employees, you create something far greater: a cohesive culture driven by a desire to do good work as a whole, and produce quality output toward a clear purpose. _That_ should be the holy grail, _not_ "unleashing your 10x performers."

Having 10x performers is surely not a bad thing; they will occur, and you should attempt to hire and keep the best employees you can, of course. But the end of this story gets even better: high performers like one thing above all else, in my experience, and that is working in an environment in which they flourish, are able to take pride in their work, and are able to work with _other high performers._ By enabling all your programmers to perform at their best, you simultaneously enable your best performers to perform better and flourish as well, which is exactly what they're looking for. Focusing on the whole system _does_ unleash your best performers; and everyone else too! It's counter-intuitive, but that's the lesson here.

The result is positive on all fronts, and not only that, but exponentially better than an individual-reward system due to the intertwined self- reinforcing effects of systematic improvements. Instead of having a handful of 10x workers, you instead build a 10x company which regularly nurtures its employees into becoming them. A 10x culture of performance.

This was the true genius of Deming's perception of the workplace, and of quality. This was never a sticking point for him; it was right there in his perspective if you look for it.

(Apologies for the length; I've been meaning to start a blog, and will sum this and other concepts up and submit to HN at some point...)

</comment></comment></comment><comment><USER4> I am going to approach this a bit from the other side. And I'll make it personal, rather than asking a series of indirect questions.

More than once, I've ended up in a position where I've put considerable effort into fixing what are often frankly the shortcomings of other co-workers. Co- workers who sometimes may be observed to be very busy discussing their weekends, or the latest movie, etc.

I've fixed conditions that come about as the employees responsible continue to be rewarded, promoted, etc. -- in short, considered "acceptable".

I tried to do what I felt and what I had been taught was "the right thing".

IN HINDSIGHT: When you find yourself persistently in such conditions, when the problem is not a one-off, GET THE FUCK OUT. Unless you can very demonstratively take control of the situation -- of the _conditions_ \-- and steer it in a better direction, you are caught in a system that will chew you up at the least and most likely, sooner or later, spit you out.

As a relatively unempowered employee, the single solution to bad management and counter-productive compensation, is to GET THE FUCK OUT.

Anything that prevents your mobility, e.g. employer-provided health insurance, a non-liquid mortgage -- I _won 't_, I refuse to, add "a family" to this list. But otherwise, any such thing becomes an anti-pattern.

One perspective on what is wrong with U.S. society these days: So many people locked into anti-patterns.

<comment><USER5> I think you're actually talking about a very different situation than the source.

The source is dealing with subordinates in each case while you're dealing with peers.

I've been in both positions.

In the case of co-workers whom you have little or no influence over, yeah "get the fuck out" is likely great advice.

In the case of subordinates, or any situation where you have the power/latitude to address things from the top down it makes sense to address the processes in place.

That said, sometimes the process that needs addressing is the identification, swift firing and future avoidance of individual bullshitters and assholes.

<comment><USER4> That's a fair point. But I did say I was approaching this problem "from the other side". Admittedly, rather quickly and off-the-cuff, and personally.

I think more readers of this thread may be in the relatively "powerless" position, rather than the empowered position.

And, again from my perspective, I wish someone had made clear to me sooner how the world really works, today (and likely always). "Paying your dues". Earning respect. There are environments in which this works. But there are many in which it does not.

From the perspective of the OP, they've already made the point. But I might add a note of succinctness. GIGO -- garbage in, garbage out. The leadership I see more clearly upon rereading and assume they are addressing: They're stuck at GI.

<comment><USER5> _> "And, again from my perspective, I wish someone had made clear to me sooner how the world really works, today (and likely always). "Paying your dues". Earning respect. There are environments in which this works. But there are many in which it does not."_

Very true. This is why I think "get the fuck out" is often great advice. Keep moving, onward and upward. Sit still too long and you run the risk of getting run down and becoming what you hate without even realizing it.

It seems to me there are plenty of books which claim to teach you how to be a great leader, but not so many about how to manage up, lead from the rear and survive among hostile peers.

Personally, one of the better resources I've read for this was _The 48 Laws of Power_ [1]. The book sometimes gets a bad rap from people who look at it as a manual for your own action. While it could certainly be applied that way, it's at least as useful for understanding the mechanism of others actions and how to protect yourself against or benefit from them.

1: [http://www.amazon.com/dp/0140280197/](http://www.amazon.com/dp/0140280197/)

</comment></comment></comment></comment><comment><USER6> This post hit home for me. I've personally implemented code review strategies which directly and immediately led to much improved code quality and generally better product. But management doesn't see code quality. They see deadlines. The insignificant time it takes for code review is the first thing that gets nixed by non-technical management even when the time required for bug fixes, last-minute changes due to their own indecisiveness, and slow development due to giving employees second-rate hardware far eclipse the marginal time it takes to make sure we're deploying halfway decent code to production. And then they bitch at the engineers that they're underpaying/overworking when shit stops working. But let's not hire more developers and improve salaries for the people we have. No, that's not what we need. What we need is more charismatic biz-dev bros with poly-sci degrees. Surely that will fix things! (/rant)

<comment><USER3> It seems like code reviews are partially for inspecting the product, and partially for teaching and inculcating cultural norms.

Are the managers who don't like this just non-technical? Or are they just not being presented the value in a clear enough way?

<comment><USER7> > partially for inspecting the product, and partially for teaching and > inculcating cultural norms

Yes!

I would go further and say that - without discounting their value for catching bugs - the _largest_ benefits of doing code reviews are cultural rather than technical.

<comment><USER8> Can you expand on what you mean by this? What cultural benefits are you talking about?

<comment><USER9> One of the huge benefits I've found from code reviews is that my reviewer will say, "Actually, we've faced that problem before and there's a solid and proved solution in our utils that handles it already, along with a couple other cases. How about you change it to use that instead?"

<comment><USER3> Yes - building on this, I see 4 quick benefits:

1 - Suggestions on where problems have been solved before. (Your point)

2 - Having people say, "Here's the _style_ we use to make this easier to support in the future"

3 - Mentoring on tougher problems, and turning quick hacks into elegant solutions.

4 - QA. (This is the stated benefit, but falls below the other 3)

The key is not to turn code reviews into a bottleneck. If you just view the purpose as any 1 of the 4, you're likely to under-prioritize or over-formalize it.

</comment></comment></comment></comment></comment></comment><comment><USER10> I agree 100%, and am especially excited to see automated testing as going from "impossible dream" (c. 1999) to "reasonable, broadly expected quality practice". It has been a long road.

However, there's one obvious problem that isn't mentioned: hiring mercenaries half-way around the world who have never met you, don't care about you, don't care about your product, and don't care about your audience.

I think it can be ok to do that sometimes, but it's idiocy to do that and expect to work in the same way as having a permanent employee who sits next to you and who will lose their job if the business fails.

Software developers, even the ones 8 time zones away, are actual human beings not coding robots with coin slots in their chests. If you are going to strip out all of the human connection and replace it with 3 milestone payments plus some spec documents, you can't expect them to care beyond what's necessary to cash the checks. (They might anyhow, out of a sense of professionalism, but you can't expect it.)

The only contracting or remote-team situations I've seen work even moderately well have done a lot to create real human connection.

<comment><USER11> Such a situation may enhance the issue the author addresses, but his point remains paramount: _don 't expect what you don't inspect._ If anything, hiring "mercenaries half-way around the world" requires _more_ of what he enumerates, which is the objectively practical form of, as you say, "do a lot to create real human connection".

<comment><USER10> Requiring unit tests is a great idea, and I am 100% behind using the techniques she describes, but it's not the real human connection I'm talking about.

One of the best distributed teams I know spends a week per month together despite the travel nightmare that entails. Another reasonably good remote project had the product manager spending 1-2 weeks every 6 weeks with the development team. Having developers participate in user tests is also great, as is finding some way for them or their friends to become actual users of the product.

If the developers don't give a shit about you or your users, you'll have to do a lot more inspecting than if they are personally fired up to make things work for people they care about.

</comment></comment></comment><comment><USER12> Code review ranks just behind design review in value (cost/time savings). In fact code reviews are so beneficial that if I was working on a solo project I would either pay for them to be done or review the code myself after a suitable cooling off period, depending on what I was working on.

On the other hand, I have also witnessed sloppy, lazy code reviews that catch nothing except the occasional typo. This amounts to an unjustifiable waste of time. Fortunately, it is easy to tell a good code reviews from bad by tracking defect discovery and digging into review comments as needed.

One thing that code review catches that _nothing else does_ is code that is poorly written but functional (i.e. passing tests).

The example I always trot out is

        for ( int i=0 ; i < this.MyControl.TabPages.Count ; i++ )
        {
           this.MyControl.TabPages.Remove ( this.MyControl.TabPages[i] );
           i--;
        }

This code works according to spec, passes all the tests, but is bordering on unmaintainable. At best it's a WTF.

(Written up here: [http://cvmountain.com/2011/09/whats-wrong-with-this-code- rea...](http://cvmountain.com/2011/09/whats-wrong-with-this-code-really/))

<comment><USER13> I find that one of the causes for wildly different levels of code review (and value derived from them) is a lack of training. There is a real lack of materials for explaining how to do a code review, how to do deal with the human aspect of giving feedback, what is/is not valuable to talk about (arguing over tabs vs spaces should not happen in a code review). Most of my experiences have involved a trial-by-fire process - new engineers receive a few code reviews from more experienced people and that is your "training".

<comment><USER12> I agree - and your comment gives me an idea for a series of posts on this exact subject.

<comment><USER13> Great - would love to read :)

[http://exercism.io/help/how-to-nitpick](http://exercism.io/help/how-to- nitpick) is a good resource as well.

</comment></comment></comment></comment><comment><USER14> Consulting has its challenges, but one of the most amazing perks is charging for value, not time. Once I demonstrate the value of the project to the client, and bill by the week, I no longer have to justify unit testing, continuous integration, code reviews, or any other productivity decision as a tech lead. I know these are the best ways to achieve consistent long-term productivity, and so that's what we do.

Learning how to sell results has not only made me more money, but a better technologist.

</comment><comment><USER15> Yeah, code review is great...until you find out that some of your reviewers are rubber-stamping the commits from their favorites, and a large percentage of the rest are doing a sub-standard job of reviewing, and _pretty much everyone_ is just barely finding the time to do the (decidedly un-fun) chore of reviewing code, instead of writing code. So you're back to the root cause of the problem: you have to hire good people.

Truly careless employees will (ironically) work hard to find ways around any system that you put in place to prevent carelessness. There are no magic bullets.

<comment><USER16> The solution is code meta-review! Just have reviewers review the quality of reviews until review quality is up.

<comment><USER15> Slashdot was the future.

</comment></comment></comment><comment><USER3> "You get what you measure" \- Tom Peters

Quality must be designed in, but people won't do the effort if it's not valued.

</comment><comment><USER17> Great read. This sentence sums it up best I think, ___" Why, why, why would people expect to get great results if they flaunt all the best-practices that have developed over the past 20 years?"_ __

<comment><USER18> I don't think he's using the word "flaunt" correctly. It struck me as off -- sure enough, the definition agrees with me.

"Flaunt: to parade or display... conspicuously. The use of 'flaunt' to mean 'to ignore or treat with disdain' is strongly objected to by many usage guides.'"

[http://dictionary.reference.com/browse/Flaunt](http://dictionary.reference.com/browse/Flaunt)

<comment><USER19> "Flout" is the word most likely intended.

flout (verb) 1. openly disregard (a rule, law or convention).

</comment></comment></comment><comment><USER20> I think these are all fantastic things to implement but do you know how much pushback you get from engineers on this:

Me: "Do you have a standup every morning, so that you know about schedule delays after at most one day?"

In general folks HATE these, but I would love to hear other cases where people have found them successful. We are small enough that the conversation is ongoing so haven't needed to implement it.

What I have done in other cases is the "walk-around" to speak to people individually rather than in a massive group meeting - and that seems to have been well received.

<comment><USER21> I think the important point is that a boss needs to touch-base with each employee daily, and how you do it is up to you.

<comment><USER22> I prefer it when mine stay out of my road and let me get on with things. They have a pretty poor understanding of software engineering, but can code enough to think their input is helpful, when it usually isn't

</comment></comment></comment><comment><USER23> So basically you want to implement Enterprise QA processes for a tiny team so as to make up for incompetence and bad hiring decisions. Sorry, I don't buy it.

<comment><USER24> Yep. I don't think doing an 'art review' is going to turn many amateur painters into a picasso.

Code reviews also suck up time of your most senior people. Personally, I'd rather just have some fucking TESTERS. (manual or automatic script writers).

<comment><USER21> You'd be surprised. A crucial part of learning to be an artist is open critiques. It is the one moment when lovey-dovey artists suddenly turn into the same kind of nitpicky curmudgeons as us coders.

Where do you think great artists come from?

<comment><USER25> As a professional developer who started college in an art major, I can verify this from personal experience.

<comment><USER21> It's funny, the similarities between a critique and a team code-review didn't occur to me until penguindev's comment. But they really are a lot alike.

</comment></comment></comment></comment></comment><comment><USER26> I definitely agree with all of the sentiments in the blog post. With the exception of daily scrum (we do twice weekly), we try to follow all of these habits. There always seem to be two things which we run into though; superficial code reviews and haphazard integration.

On the code review side, I find that most engineers look for trivial crap that could normally be picked up by running lint. It's nice to have similar lint-y style, but for me, the most important things to look for are whether the code is going to break with unexpected input (ie. is the logic sound and are the unit tests good enough), and did the engineer write in an idiomatic style which would be easy for other engineers to understand. I don't mind comments like "maybe use this other variable name", however using recognizable patterns which allow other engineers to easily follow the logic is much more important. Often it seems like people get lazy during reviews and write really superficial comments instead of taking the time to really get down and dirty in another person's code. And why would they? They've got their own code to write.

The other thing I feel like I'm always up against, particularly with younger engineers (sorry younger engineers!) is not thinking through all of the integration points when your code needs to work with other code which is being developed concurrently. One engineer will say something like "Oh, just call function X", which when you do, doesn't provide the functionality which the other engineer was claiming it had. That, or there was some additional step which one engineer wasn't being explicit about and there was an assumption that you were going to take care of it. There's nothing worse than finding this out on the last day of the sprint when you're trying to button everything up.

</comment><comment><USER27> There are lots of software developers out there, that shouldn't be developing software in first place. They could be excellent farmers, musicians, athletes, but for whatever reason they decided to be software developers. And it doesn't matter how many scrums or code reviews you throw at them, they just won't get it. They will be producing miserable results making everyone around them miserable.

On the other hand, there still are a few decent, old school devs, who don't need hand-holding, constant poking and distraction of standup meetings and writing meaningless test cases that check if 2+2 is still 4. They just (1) understand the problem and (2) write code that solves it. As simple as that. Good old engineering, like these guys: [http://www.youtube.com/watch?v=8kUQWuK1L4w](http://www.youtube.com/watch?v=8kUQWuK1L4w). Or original SAS system - its reference manual was better quality then any statistics textbook. Unfortunately those days are gone now and we live in the kingdom of Scrums and Frameworks.

</comment><comment><USER28> This may not be obvious to some people (like my boss), but code reviews alone is insufficient; having a good technical design early on is more important.

I've sat through several "code reviews" and they're always conducted at the end of small-ish projects and when I look at the code, I would very much want the guy to rewrite it but by then it would have been too late.

</comment><comment><USER29> I feel like we're not getting the whole story. For example, what do you do when you follow all these best practices, but end up with a product that no one wants?

</comment><comment><USER30> We've tried to institute technical design docs and reviews and failed.

Management keeps asking we do them but doesn't enforce it.

Developers don't want to do it and take it personally when you suggest a different approach during the review.

Management sets deadlines on projects without consulting leads or architects.

I (database architect) have suggested we add steps for technical approval and code reviews to our feature/bug tracking system but have been ignored.

I'm sure people can relate out there.

<comment><USER31> You need to read "Good Boss Dead Boss".

<comment><USER25> This book? [http://www.amazon.com/Great-Boss-Dead-Ray- Immelman/dp/097403...](http://www.amazon.com/Great-Boss-Dead-Ray- Immelman/dp/0974036919)

<comment><USER31> Yes sorry. (Can't believe I didn't remember the title. I'm reading it right now and it's sitting on my desk. _FacePalm_ )

</comment></comment></comment></comment><comment><USER32> I know that these points are often touted as best practices. I agree with most.

I have _never_ seen useful (daily especially!) standup meetings.

That very well might be a cultural problem or an issue with the people I work with etc., but even after giving the idea a couple of chances: 'Daily standups' make me cringe inside.

</comment><comment><USER33> Building automated test is like getting a flywheel going. Sure it might be difficult to start, but once it's gets going, it will take you very far with little incremental effort.

</comment><comment><USER34> Does anyone have a resource for a full checklist of practices? I'm a processes guy but I'm curious what all is out there these days.

<comment><USER35> I don't think you can beat the joel test for simplicity. It's a bit dated perhaps, but still surprisingly relevant.

[http://www.joelonsoftware.com/articles/fog0000000043.html](http://www.joelonsoftware.com/articles/fog0000000043.html)

<comment><USER34> Oh wow, I remember reading this years ago, but it's still surprisingly relevant (took the words from me :) ).

</comment></comment></comment><comment><USER36> Perfect analogy with the architect.

</comment><comment><USER37> Early impressions of the article:

some of that is getting what you pay for. If you go after cheaper or younger people, you're more likely (all other things being equal, general case, etc etc) to get lower quality work. Also, there's a self-created problem factor where if you force somebody else to give you an estimate (which is just a guess however much you pretty it up and repackage it), and then turn that around and treat it as a deadline, then you can expect those deadlines to go whooshing past. And it will happen even more often if you have cheaper/younger/less-experienced programmers.

Hire better people, which also means paying them more. And don't ask for estimates. Just see what happens, and iterate.

</comment><comment><USER38> Long story short, I get put on performance review, threat of termination. Boss gives me exacting standards for project to complete by X date, reviews everything I do and I have to write a progress report every 2 days that's reviewed (usually). Boss asks, "why did your performance improve so much?"

I'd never even seen a project plan before a few months ago...</comment>