Ask HN: CTO vs. VP of Engineering - <AUTHOR> Note: I'm posting this under a different account than I normally use on HN because I want to remain anonymous.
For the last 2+ years I've been the CTO for a technically successful startup.  I have successfully navigated the company around some very real disasters and have built a highly dedicated tech team that has excelled at realizing the technical vision of the product; despite whatever curve balls have been thrown at us - externally or internally. In those two+ years, I've worn every hat one could wear (from IA to project management to product development to systems admin to front end development to back end development) and have worn those hats as well as I could.  We've staffed up to the point that I no longer am wearing as many hats, which I am grateful for, but still have a few key roles to fill, mostly in the project management category.
Several months ago, we hired a new CEO, whom I partially respect, but don't necessarily like.  As is typical, his first criticisms were aimed squarely at the tech team because the tech team is always the first to blame - despite the fact we've always done what we said we would when we said we would.  Obviously, as the only part of the company that produces tangibles, it's fairly easy to square operational issues on us.  I've fought those criticisms as well as I could, but have been unable to make him see the real problem is the front office's lack of vision and an inability to communicate clearly whatever vision they might have.  I've done the best I can given the sheer number of things I am required to do during the day, but, as anyone can correctly surmise, isn't the best I could do if I had a more singular focus.  It's really hard to context switch from installing nagios on our production servers to doing IA to doing project management; all within the span of a few hours, day after day.  It wears one down.
So he recommends we hire a VP of Engineering, which I agree to.  It makes sense.  Let that person run the process and let me focus on the bigger picture, architecture, product, etc.  But then I read the job description and notice the line where it says this role reports directly to the CEO.  Which means, since the entire tech staff is reporting to the VP of E, that I lose my staff.  When I bring this up with the CEO, he tells me that I should see this VPE as a peer.  Say what?  It's bad enough that I have to explain to employees that have been with the company for 2+ years they are going to have a new boss, but now that boss doesn't even report to me?
Am I being paranoid that I'm being marginalized for an ill-perceived picture of the tech team?  Is the CEO playing politics?  I'm at a complete loss.
Advice? <comment><USER2> The CEO has decided that you have technical ability but not management ability. He doesn't want to lose your nagios-installation skills but he thinks that an imaginary person whom he has not yet met or hired will be better than you at leading the tech team. He's happy to let you keep the fancy CTO title and perks so you don't lose face, or because he doesn't want a confrontation.

I would guess based on your comments and the fact that you're asking this question that politics are not your strong suit. "Politics", b.t.w., is just the natural state of people working together... it can be dysfunctional or functional, but as soon as you have 3 people, you have some kind of politics.

Since politics are a major component of management, you may actually be happier not doing management.

In situations like this the CEO is probably overestimating his ability to find a Magical VP Technology that will magically solve all his problems (unless he has someone in mind, a buddy from a previous company, for example). Likely he will spend 6-9 months trying to find someone, finally hire someone imperfect in despair, and spend the next year or two discovering that person is incompetent, too. But now I'm really just projecting.

If you don't like the CEO it may be time to move on. Life is to short to work with people you don't enjoy spending time with.

<comment><USER3> I definitely read the same thing as spolsky, based on your language that you're not nailing the managing up and out parts of the VPE role, which is why the CEO is looking for someone else.

I know a lot of people project negative intentions onto the CEO in this situation, but it's his job to make a call about what's needed here and it seems like his call is that you aren't up to snuff. At the VPE level, it's not enough to be technically right, you need to be able to turn the engineering group into a cog that runs with the other cogs that the CEO is putting in place.

When I was in this position our board introduced me to some potential mentors with more VPE experience. They all had one identical piece of advice: measure everything and then use that to control the dialogue about engineering with the board and the other managers.

That advice seemed overly political to me (especially the bit about controlling the dialogue). I've come to two realizations about it.

One, a lot of the people who judge you have extremely strong personalities and if you aren't presenting an equally strong opinion, then you won't be able to have a conversation as equals. Facts are what give you backbone.

Two, when you put down an engineering process, half the value is in making your team more efficient, and the other half is in presenting a predictable interface to the rest of the company so that they can get their jobs done. That outward part of your responsibility was the key realization as these people took on more responsibility.

I don't think all is lost for you. Some people would probably project onto the CEO that he has a personal dislike for you, but all you can really infer is that he wants a different type of leader in the VPE position. You would show that type of leadership if you went to him, explained the problems/risks of finding an experienced VPE, and then laid out your plan for becoming that person including asking for a mentor and a proposal for an engineering process that gave him more insight into the company.

Now you might not want this role or might not have the opportunity. In that case, life is too short. Go start your own company.

I think the situation if fascinating and wish you'd left some way to contact you. You should definitely put together a strategy for any of the roles, VPE, CTO, or former-employee, and get some good advice.

</comment></comment><comment><USER4> In my company, the CTO and CEO are the co-founders. The CTO has a PHd and our revolutionary product is pretty much his brain child implemented by the tech staff under them. We also have a VP of Engineering that they hired. (a Director of Eng in their previous venture). However, the VP of Eng reports to the CEO. The CTO has his own set of staff and they basically brainstorm on new ideas. We engineers respect all of them, but the CTO is definitely placed at a higher pedestal because the bread & butter produect being his idea. But, the CTO does not deal with most of the engineering staff except a few members who are working under him for some latest ideas or our product in the R&D phase, not released to the market yet. As an analogy, the CTO is more like a College professor with a bunch of RA's under him :)

I am not sure what your background in your company is. Just wanted to share what i saw in my company.

</comment><comment><USER5> Sounds to me like he's trying to push you aside.

</comment><comment><USER6> It's normal for the VP Eng to be a peer of the CTO and report directly to the CEO. That said, you are almost certainly being marginalized. Your CEO likely knows he needs your irreplaceable understanding of the company's technology, but otherwise wants you out of the way.

Replacing you as manager is probably not going to work out well unless he already has someone good in mind. CEOs rarely understand how much difficulty they'll have identifying competent tech managers. He's in danger of finding someone who does a great job of "managing up" and a poor job of getting things done efficiently and correctly.

If you can't prevent the hire, making sure you hire someone competent is probably the most significant thing you can do for the company.

<comment><USER6> I should have added: if you _can_ prevent the hire, probably the most significant thing you can do for the company is to learn how to correct the problems, real or perceived, that have led to the desire for a new engineering manager.

</comment></comment><comment><USER7> It sounds like from what you are describing, you are more like the VP of Engineering and less the CTO of the company. VP of Engineering should report directly to the CEO and should be responsible for the entire engineering staff, similar to the VP of Sales who also reports directly to the CEO and should be responsible for the entire sales staff. If the CEO believes that he needs a new VP of Engineering, then essentially he is telling you that he is not happy with your performance and he needs to replace you.

</comment><comment><USER8> I worked in a company where the VP of Engineering didn't report to the CTO. It made some sense because the CTO mostly directed the 6 months into the future vision of the company (next features, next product). This worked ok because the CTO had a research team that reported to him and the VP of Engg had the development team reporting to him but it was not optimal.

The issues we faced were:

\- CTO+Research team builds some amazing enhancements for the product but have to fight to get them into the next release (Dev claimed there was no time for regression testing..but next cycle there will be)

\- Dev team thought the research team were ivory tower elites (even though this was not the case). There were Ph.D.s and people who never went to college on the team.

\- Research team eventually thought they were superior (reaction to having all their input regularly ignored by dev team)

In short, if your company has a legitimate need for a research or forward looking team, there may be a way to make this situation work, but not without regular political disputes and bitterness between teams. Try to find a way to have the VP report to you.

</comment><comment><USER9> At my old company we called the CTO "chief termination officer". It was basically the de-staging area for tech people who had enough visibility that they didn't want to get rid of them outright.

</comment><comment><USER10> I'm skipping over the issue of your CEO's motives - he could hate you and want you out, but assuming he doesn't..

 _despite the fact we've always done what we said we would when we said we would._

So you've got the commitment thing down: you make commitments and then stick to them. That's a reasonable baseline for reliability, but there is a whole world of value-add beyond it. The VPEng should be working to improve the company's ability to deliver product - even when the problems that need solving aren't with his direct reports.

In particular, you say the front office has problems communicating their vision. Do you work to improve their flawed and/or vague requirements, or do you let them hang themselves, and point to the requirements document when they're unhappy with the end result?

Longer term, have you tried to move towards more iterative processes (prototyping during requirements gathering, agile processes, etc) to reduce the damage done by poor requirements?

You sound like you are happier around, and have performed better in, the technical aspects of your job than the management aspects. Your CEO may (grain-of-salt) have noticed this. He could even be trying to give you what he thinks you want.

Consider that your CEO may have a management structure in mind where the process-and-timelines guy sits between him and the development team. Maybe you could have this job if you wanted it - but it would mean hiring a CTO to worry about the bigger picture, architecture, product etc. Your boss probably doesn't want to pervert the reporting structure he has in mind just so that roles in it matches what you want to do.

</comment><comment><USER11> [http://www.feld.com/wp/archives/2007/10/cto-vs-vp- engineerin...](http://www.feld.com/wp/archives/2007/10/cto-vs-vp- engineering.html)

</comment><comment><USER12> New CEO probably thinks that the engineering team is a mess and someone has to fix it. Stop implementing Nagios yourself (and any non business critical issues), and ask the CEO for some freelance to do the job instead. If he argues that he has no money for that, run away fast (he has money to hire a VP Eng...). If he agrees, then start building a trust relationship with him quickly. Tech tasks usually can wait, where your CEO cannot (yes computers are nicer than CEO, but CEO signs your paycheck) Focus on customer needs and your colleagues' need: how can you help sales/presales and marketing do their job ? Ask them what they need to succeed and give them the product they need. If you cannot because you don't have the resources, be clear about it and have them decide which tradeoff with you (or have the CEO allocate more resources). Become accountable: Learn to say "No" to mission impossible and avoid saying "No" when you could if you had more resources, just say "I could if ..." and have them participate in the tradeoff decisions. Write things down once the decision is made and email it after the meetings. If you think that this is too late for that, or that the sales/marketing guys have no clue (or are trying to cover), quit... and start again elsewhere.

</comment><comment><USER13> The new CEO is taking away your advantage of working in a startup: \- when you were CTO, you were critical for the company. When the VP comes, you will eventually become commodity (and expandable) \- your influence in the company is being cut into half \- you will lose your flexibility (or agility) in getting things done (the process guy also now has to put his say)

Talk to the founders and the new CEO. If the VP engg. makes sense have him to report to you. If not move on like Spolsky says.

</comment><comment><USER14> You're being marginalized. But I'm not sure if you're capable of being VPE but are being passed over because the CEO wants to bring in a buddy or because you are genuinely extremely unsuited for the job.

If you don't want to be marginalized, fight to get the VPE position. If you're going to get fired or further marginalized for fighting, you might as well learn now so that you'll win next time. If you get VPE, learn the skills required to be a great VPE and prove him wrong. Ask point blank for the position and find out why the CEO thinks you're unsuitable for VPE.

For some reason suits think management is not learnable/teachable. You sound smart; it's quite possible you'll be able to learn the required skills.

IMHO, people who think management is about "people skills" and "politics" are the clueless ones. Read up "High Output Management" by Andy Grove, a hard-core geek if ever there was one. He turned out to be an amazing manager too. Bill Gates, even harder-core nerd also turned out be an amazing manager.

To my mind, management is more similar to programming than to party planning (where people skills are really required). The manager's job is to set up systems and processes which will result in maximum output. To do this, you need to be analytical, quantitative, data-driven, open to being proven wrong etc. Do you see how you've been practicing all of these skills as a techie? Do the same for a proper manager's job skills and you'll see the overlap.

As an aside, I think all managers should have some individual responsibility also. Otherwise they will be tempted to create problems that can be 'solved' to justify their existence.

Re: "politics is not your strong suit" comments: you're expect things to work rationally but they seem to be irrational. Being techie who's always open to the possibility that you might be wrong, you're getting a second opinion to check your conclusions. Nothing wrong with that; that's a strength.

</comment><comment><USER15> work on your resume dude, and start going to lots of parties. Or just suck it up and make yourself as useful and unobtrusive as possible (times be rough out there). The CEO wants to sideline you; you're not his guy. He needs someone malleable and loyal to him only.

Read The Prince.

</comment><comment><USER16> Two cents here. Similar situation happened to myself, except I wasn't the CTO but the de-facto "lead architect" of a major project/death march that had all of the stereotypical problems you read about again and again: product mismanagement, feature creep, overzealous salesforce, and heightened expectations reaching the impossible.

Much like yourself, I had been put in charge of an incredibly difficult project and somehow managed to grow a solid engineering team and build the system with them and get something out the door. 500k lines of C#, unit tests integration tests, the whole 9 yards over two years. We had finally launched (late and with much more baked in than accounted for) and started to tighten up iterations and bring in customer feedback. (Yes! We really had no customers using our system for two years during development!) I of course was under a lot of stress as feature backlogs grew and defects lists exploded because the software wasn't rolled out slowly and incrementally to clients but instead sold from day zero as if it was 100% rock solid.

So, as you probably had, I had my lunch with the CEO where I was being asked (ie told) that a new VP of Engineering position was going to be pursued to fix all the horrible problems plaguing the software development team. The problems which, at least from our perspective, had little to do with us since we pulled off not one but a series of those small miracles that only happen at 4AM by yourself in the tech room. However, taxed was I and naive, so I figured hey, what the heck, maybe I'll be able to write code some more if this magical hypothetical person can swoop in and take care of all that other nasty business like "talking to the sales guys and telling them not to sell features that don't exist."

So, we interviewed for this position fully unaware of what it was, exactly, we were looking for. Being young engineers if a candidate came in and had managed teams before _and_ knew what unit tests were we were thrilled. We had no idea though what to look for, what red flags there were in hiring this person, so the third person or so who came in to talk to us ultimately was hired since it's hard to say no to someone who you don't even know how to judge. (And you can't, of course, just hire the first or second candidate that walks in the door because then you just look like you don't know what you're doing!)

So soon after this new hire we began interviewing for additional developer positions, but all folks that came in to meet us for interviews were developers this new VP of Engineering worked with in the past. As it turns out, the first candidate didn't know how regular expressions worked, so I said "no hire." The second, turned out, worked with a friend of mine some years back and spent days on end simply reorganizing the file structure of their svn repository, and so again, I said "no hire."

Well, they both still work there and I have long since left. Our system we worked on for years completely thrown out for yet another re-write from scratch, now to be done the "right way". The all stars on the team I helped build are all gone except one who has a family to support, all moved on to do startups or larger more innovative software companies.

A long story, yes, but I'd urge you if nothing else to consider the impact a hire like this can have on your entire team, since they will now be the ones making the hiring decisions. If you cannot trust them with that (and it's hard to trust anyone with that after just a few interviews), I'd say push back as hard as you can on this particular decision and try to, as PG says, "be resourceful" and bootstrap solutions from folks already in the organization you _can_ trust.

<comment><USER17> ". Similar situation happened to myself, except I wasn't the CTO but the de- facto "lead architect" of a major project/death "

Ohh that brings back memories. A Senior Vice President at one of the largest software companies in the world asked me to meet him because he was looking for a "lead architect" for an "elite group" he was putting together. I met him and went over what he needed in detail and it seemed like there was a good fit (and the senior VP was a very nice person).I specifically asked him " So who makes technical decisions? " the answer "You do of course, you are the architect. You'll be reporting to me so just keep me in the loop". So I accepted the offer.

By the time I joined a week later, I found that I would be reporting to a (newly hired) "Director of Engineering" and would have a "dotted line reporting relationship" to a "Chief Architect" (who in turn reported to a [Company] Chief Architect. The VP Engg chap I reported to (he turned out to be a very Dilbertian middle manager type) reported to a VP India, who reported to a Senior VP, Emerging Markets, who reported to yet another VP who reported to the CEO. The "Chief Architect" who I had a reporting relationship with was a very nice person but couldn't code to save his life and always spoke in very abstract terms like "scaling Enterprise SOA across business units".

The VP who hired me led a "product development" group totally disconnected from what we were doing.

I found I could make hardly any decisions but had to attend plenty of meetings about meetings. A memorable meeting was when I had to deal with the "General manager (SCM)" to demand Licenses of the company standard proprietary Version Control system for my team and he asked me "Do you really need Version Control? Couldn't you just use directories? Make a directory per version and save your code in it. We back up all the directories every day "(!!).

Long story short, I felt like I was working in Arkham Asylum but the money was good so I stayed a few months and left with a nice bank balance and am now back in consulting mode.

Getting back to the point, from what I've observed of company politics it looks like the CEO has a two step plan to get rid of the Original Post-er. First, cut away your power base by having all the dev chaps report to the new guy and then ask " so what does he do here anyway?". He probably just wants to keep you around for a while as "insurance" . If I were you (depending on how much power you have with the board/founders) I would either (a) make sure I had some real work to do as CTO (in the corporate world this often means having people report to you )even after the VP chap were hired (b) make sure the hire didn't happen, in practice this depends on how much clout you have in the existing setup or (c) start making plans to leave.

The good news is that even in he case of option (c), you have some time to make your move. If you have a sound enough financial base, you should probably quit immediately.

My 2 cents. But ultimately only you know the finer details of your situation that make a difference.

Good Luck man!

</comment></comment><comment><USER18> Traditionally, CTO is responsible for eliciting business requirements, designing and developing technical solution and coordinating project activities.

VPE is responsible for deployment, technical support, bug fixing and coordinating marketing activities.

</comment><comment><USER19> The VP need not marginalize the CTO, often he just removes tedium from the CTO. If you get a VP Eng and modify the company org chart, and at the same time your influence in the company dwindles, I don't believe it will be causation.

</comment><comment><USER20> This is a rough question - but are there areas in the tech area that you see requiring improvement? If so, what are they? Irrespective of the political state, do you see the CTO/VPeng setup redressing them?

</comment><comment><USER21> I'm the guy on the other side of the table: I'm the VP of Engineering who gets brought in. The circumstances are always the same - the CEO/COO/BoD doesn't believe that the CTO is the person they can trust to build great software and great processes. (This may or may not be true, and the company may or may not be doing that already - I've seen both. This is subjective even if you know what you're talking about.)

A few simple notes, and please know I don't wish to be insulting, just clear:

\--This person is absolutely going to report to the CEO. The CEO is the person making the decision, and if he trusted you to build and run the organization, he would have had you hire the VPE. (On a related note, you missed an opportunity to fill a hole for the company that the CEO recognized.)

CEOs (and any leader of a large, multi-fxnal organization) want their direct reports to be the people they can trust to get something done. You aren't that guy - the CEO doesn't want to go through you to find out how the engineering org is working, or he would have kept you in charge - so the VPE isn't going to work for you. Done.

\--The CTO/VPE peer relationship is perfectly reasonable. Sometimes it's a hierarchy, sometimes it's not. Usually when it's a hierarchy, it's because the CTO also runs other groups (like ops, tech support, etc.), and so is known by the CEO etc. to be a capable manager. You are not.

So when I read your note, I can't tell if

1) you're upset because you want to keep doing the VPE job, but you aren't going to get the opportunity; 2) you're happy doing the CTO/Chief Architect job, but are frustrated/saddened by how it was handled.

You really do need to make this call. If it's #1, sorry - best you can do here is help hire a great VPE and leech on to learn from her. (Lot to be said for that.)

If it's #2, the good part is that if the VPE is the right kind of egg, this can be very good for you:

1) Many VPEs do this job because they don't want to be the Chief Architect. Some have the capability, some did once, some just don't, but you rarely have someone competing for your job or responsibility.

2) You get to wipe your hands of everything besides making sure the company technically designs great software. As a company grows, that's a huge bonus. You have to genuinely _want_ to do this job when things get ugly or when negotiations get tricky.

3) Your time with the CEO almost certainly diminishes, but that's ok, because you get to work with the people who matter more to you.

I like what I do, and when I find a great CTO, that's awesome - it means that I can help on architecture occasionally, but really I get to focus on the problems I'm there to solve, knowing that many eyes are keeping us out of architectural trouble. So, make a friend (and if you're in Seattle, I'm always available).</comment>


The traveling German carpenters - <AUTHOR> http://blog.intellum.com/2011/04/traveling-german-carpenters.html <comment><USER2> My good friend is a journeyman, and I always wished there was a US equivalent, especially in the realm of software engineering. I'm sure a lot of people would enjoy coding with brilliant programmers and traveling around the country.

Anecdotally speaking: My friend has a "wunderstick", which is a hand made walking stick. When we go into bars in Germany, he taps it, and the bartender gives us free drinks. Before we leave, he taps his stick again, and says some big speech in German (about how grateful he is, etc). Most bars and hotels cater to the journeymen quite well. While we were in Berlin, he also had girls run across the street to him and kiss him on the cheek or lips. I guess it's good luck to kiss a journeyman.

<comment><USER3> Actually, there are journeyman software developers. Here are some links:

1\. Corey Haines: <http://programmingtour.blogspot.com/>, <http://www.coreyhaines.com/>, <http://www.coderetreat.com/>

2\. Journeyman Programmer Description: <http://teamdoty.us/journeymanwp/?p=4> (from <http://www.thejourneymanprogrammer.org/>)

3\. Software Craftsmanship: <http://en.wikipedia.org/wiki/Software_craftsmanship>, <http://scna.softwarecraftsmanship.org/>, <http://www.softwarecraftsmanship.org.uk/>

</comment></comment><comment><USER4> This article talks only about journeymen and women who are truly exotic and rare but it doesn't really emphasize that vocational training — the alternative to college — still is alive and well in Germany. You usually don't got to college if you want to become a hairdresser or a mechatronic engineer.

After they finish school, the apprentices work three or four days per week at some company and go to a vocational school the rest of the time.

<comment><USER5> The German system indeed has a lot more options between a full blown academic career to learning a craft in a structured 4 year program all the way to being an unskilled laborer with 10 years of school.

The drawback is that career paths are also more structured than in the US and take a long time. Want to start a painting business? Better get your Meisterbrief first and that will take a good while.

Here in the US things are more fluid, which leads to people changing careers and going back to school at a later age more willingly. The flipside is that almost everyone is an amateur and quality of work varies wildly.

</comment></comment><comment><USER6> Yeah I experienced this growing up as a kid in Germany. I remember these people from other towns in their "strange" outfits. Over the years they got less and less but you can still find a few.

Now living here in the U.S. I wonder how something like this would maybe translate over to coders and designers in startups. Seeing that we have these startup heavy areas across the country. Why not have people work a year in the Valley, then move a year to NYC, followed by another year in Boston or Austin. Would be a fun and rewarding program for young talent.

<comment><USER7> No need for a program - you can just do it. Even go outside the US (some countries have a work/holiday visa program, eg Australia). It's a great learning experience.

<comment><USER6> Yes of course one can just do it. But having a bit of an umbrella organization around this would help get the word out.

<comment><USER8> What would we need to create one?

<comment><USER6> I think the most critical step towards success of such a thing is getting a few bigger companies in each of the startup areas to offer exclusive intern/entry/mid-level positions to these kinds of people.

<comment><USER8> I guess a lot of hacker news reader work in said startup areas. So is anybody willing to give it a shot?

I am located in Munich, Germany, not exactly a startup hup, but I have some connections to Berlin and would be willing to annoy my contacts there until they agree.

Also should the plans for my own company work out in the next months, I would be willing to offer exclusive intern/entry/mid-level positions.

<comment><USER9> I'm in Cambridge, UK, but come from Germany and have seen the Walz. I'd be interested.

<comment><USER6> I was born and raised in Germany as well but am now in Dallas getting ready to move to Palo Alto.

Besides this digital Walz it might also be interesting to start a small network for "Global German Tech Talent" or something. I know there are a few germans in the Valley.

<comment><USER9> That might actually work in practice. But in principle selecting on the basis of nationality always sounds silly to me. (But I guess I'm just being a good German here. Where not even our President is a patriot.)

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> It's worth keeping in mind that the travelling carpenters are a souvenir from dark times in Europe, when economic progress remained extremely slow because craftsmen were evaluated by their belonging to a guild and would not compete.

<comment><USER11> It's worth noting that those 'dark times' were periods of perfectly ordinary economic growth compared to the rest of the world and all the millenniums previous.

Comparing those times to the Industrial Revolution that came shortly after is a little unfair - _no_ tradition or souvenir compares well.

<comment><USER12> Eh, no. The first explosion of efficiency and economic prosperity was in Roman times, when there was peace in much of Europe and cities flourished, complete with sanitation systems, elaborate transportation networks etcetera.

When that crumbled, city states took over, and economic life was once again dictated by the whims of rulers who in reality depended on keeping the ruling classes of the cities in their empire happy; in these cities, tradesmen classes operated in rigid, protectionist and mercantilist guild systems. There was stagnation and in many fields enormous regression until the Enlightenment and the Industrial Revolution (when freedom brought back the drive for progress).

<comment><USER13> Exactly.

Economic activity centered on agriculture where efficiency increases were minuscule. Because of this economic activity did not grow much.

See this diagram for an idea of just how little growth there was:

[http://en.wikipedia.org/wiki/File:World_GDP_Capita_1-2003_A....](http://en.wikipedia.org/wiki/File:World_GDP_Capita_1-2003_A.D.png)

<comment><USER11> On a small base (like a graph where the initial datapoints are less than 1/27th the ending datapoints), even large percentages can be hard to see. And I'm not sure how you can be agreeing 'exactly', since the Roman empire was as agriculturally based as anything else around (latifunda, panem et circenses, the Egypt grain tribute etc.).

But you are right that the annual growth due to _efficiency_ was relatively small:

> Indeed generations of English schoolchildren have read, probably with bored > bemusement, of the exploits of such supposedly heroic innovators as Jethro > Tull (author in 1733 of An Essay on Horse-Hoeing Husbandry), "Turnip" > Townsend, and Arthur Young. But this agricultural revolution is a myth, > created by historians who vastly overestimated the gains in output from > English agriculture in these years.4 The productivity growth rate in > agriculture was instead modest, at 0.27 percent per year, lower than for the > economy as a whole. But even these modest gains represented considerably > faster productivity growth than had been typical over the years 1200–1800. > Figure 12.4, for example, shows wheat yields per seed sown in England from > 1211 to 1453. Medieval agriculture seems to have been totally static over > hundreds of years.

(Clark remarks elsewhere that agricultural productivity growth is more like 1 or 2%, and the Chinese had easily double England's agriculture efficiency, but because farming is a war against entropy, with land being damaged and local pests adapting etc., the net productivity growth is small.)

Economic growth came mostly from population growth and exploiting additional natural resources.

</comment></comment></comment></comment></comment><comment><USER14> In France there is a related system, "les Compagnons du devoir". However, it exists for carpenters, masons, sculptors, bakers, etc. Almost all hand crafts, in fact. They must travel around the country to learn their craft, and present a "masterpiece" as a proof they master it.

<http://en.wikipedia.org/wiki/Compagnons_du_Tour_de_France>

</comment><comment><USER15> Reminds me of a proverb from Nassim Taleb: "Skills that transfer: street fights, off-path hiking, seduction, broad erudition. Skills that don't: school, games, sports, laboratory - what's reduced and organized."

</comment><comment><USER16> Back when I was in undergrad, I met a German exchange student who mentioned something about this. He may have been part of it at some point. They have a special belt buckle or something which identifies them and he said it was almost a status symbol (the belt buckle). I believe he was a roof-shingler and not a general carpenter though.

</comment><comment><USER17> I really wanted to see those beer-giving sticks, and found that the magic google word for more pictures is 'Wanderschaft': <http://www.google.com/images?q=Wanderschaft>

<comment><USER18> Sorry, but "Wanderschaft" is a rather old fashioned word for hiking. It is the noun version of the verb "Wandern" (to hike).

The stick is called "Wanderstab" or "Stenz".

<comment><USER19> "Wanderschaft" is the German noun used especially for the carpenters journey.

</comment></comment></comment><comment><USER20> Corey Haines has done this with software development. In a similar fashion working for room and board. Which turns out to be a great deal for the company and I assume great experience for Corey.

<comment><USER21> He has a blog at <http://programmingtour.blogspot.com/> but I don't see where he talks about programming for room and board.

</comment></comment><comment><USER22> Did anyone else read that title as "time traveling German carpenters?"

Does the internet make this less relevant for those in the software field?

<comment><USER8> The "Walz" is not for building primary skills (i.e. in our case Software Development or in their case Carpentry). It is assumed that carpenters doing it are already quite skilled in their respective profession. The reason of the "Walz" is to teach self reliance, soft skills and to round out ones primary skills by being exposed to practices of their craft that have evolved/developed differently from those they learned during their apprenticeship.

In short the goal is to become a "Master" which in the german vocational tradition originally meant having your own shop and not needing to be an employee any longer (so in our case to become a founder).

I think the internet undermines these goals, because, well IMHO it is becoming more and more a gigantic echo chamber (we all read the same blogs/books, admire the same persons, use remarkably similar tools etc.)

I think it is astounding that a lot of very smart people assume that currently hip and promoted best development practices, say for a Web 2.0 whatever platform are relevant for other areas (e.g embedded, big iron, medical, aeronautic, finance) because there is not much evident push back in the blog sphere from practitioners in these spheres... which AFAIK is more a result of these people tending to much less likely to blog or work on open source software, than of the universal applicability of said practices (and if the push back, the results I have seen so far have been highly embarrassing for the hipster crowd).

<comment><USER23> _In short the goal is to become a "Master" which in the german vocational tradition originally meant having your own shop and not needing to be an employee any longer_

Not just originally, for some professions you're _still_ not allowed to have your own business without your "Meister" degree. Never understood why this included hairdressers…

Totally agree with your assessment of the web subsection of the IT profession. And it's quite splintered, with the "young turks" against academia against the enterprise, with plenty of small areas of expertise vanishing in the cracks. It does get a bit better if the forum of discussion is sufficiently abstract and spread over different niches (e.g. programming languages that transcend specific fandoms).

</comment></comment></comment><comment><USER24> Interesting article, it's one of the directions I want to take with Answer in 30. We're very people focused so I think it's essential to be out and about with the 99% of people who aren't tech startups, getting work, getting to know our customers and seeing how our product can make their lives better and businesses more successful.

I want to take a van and travel North America working on the startup and talking to our userbase and customers. What could be better from a community management perspective than to get a visit personally from the founders. I think it says a lot more than some silly badge you can display on your profile.

</comment><comment><USER25> Funny, I have seen these guys in a bar a few months ago (in Germany). I didn't talk to them. However, that would've been interesting I guess. Anyways, interesting story.</comment>


Functional core, imperative shell (2012) - <AUTHOR> https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell <comment><USER3> This basic idea has deeply infected how I approach software architecture and design. When someone asks me why I wrote something a particular way, it's usually because I'm trying to keep the imperative/environmental concerns separate from the functional/algorithmic concerns.

I end up recommending this video at least once every year.

(EDIT: Another one from Gary that pairs well is "Boundaries": [https://www.destroyallsoftware.com/talks/boundaries](https://www.destroyallsoftware.com/talks/boundaries) . The core idea is that _values_ \-- data, not code -- should form the boundaries between distinct systems.)

<comment><USER4> The actor model is prized in the talk. Yet actor model is not functional. The problem is the message queue of each actor. It is an imperative storage and one can get all nasty problems of imperative code from apparently functional code patterns.

<comment><USER5> What would a functional approach be?

<comment><USER4> It depends on what is the goal. To take advantage of multicore for computations one can use explicitly parallel functional algorithms. To improve response under load one can do load balancing within application and schedule at the very top (shell level) several independent functional pipelines.

</comment></comment></comment></comment><comment><USER6> One of the things I really like about this approach is how well it lends itself to separating what needs unit testing from what is unsuitable to unit testing and should instead be validated by higher-level end-to-end/functional testing.

I think it's also related to the concept of building a DSL in which to implement business requirements. Once you have the right 'primitives' you can then combine them in useful ways that are easy to verify (by reading the code) that the implementation matches the requirements.

<comment><USER7> How do you deal with performance problems? I mean to add an element to a list you need to create a copy of the list and then add the new element, all in order to remain functional. Isn't that very expensive?

<comment><USER8> You only have to copy if your array is implemented as a simple linear sequence of memory addresses. More advanced implementations don't have to copy everything. E.g., Clojure's vectors (its array equivalent) are effectively O(1) for the common array operations that are O(1) on naive arrays, like indexing and insertion. But Clojure vectors are still purely functional. (The actual time for some of those ops is O(log32(n)), but log32(1,000,000) = 4, so it's effectively O(1).)

The term for this is "persistent data structures", usually implemented via trees, where replacing an object in a vector is implemented by building a new tree, reusing all of the old nodes except the ones that appear in the path from the root to the replaced node. That's why Clojure's Vector is log32; it's a 32 b-tree. (I'm writing this from memory and have little Clojure experience, but I'm pretty sure I have it right.)

Many languages have implementations now, but most aren't as fast as Clojure's. E.g., there's immutable.js: [http://facebook.github.io/immutable- js/](http://facebook.github.io/immutable-js/)

<comment><USER9> For people who are interested in these things, I'd highly recommend Chris Okasaki's thesis/book on the topic.

I was not familiar at all with this stuff when I read through it the first time, so it was a tad mind-bending and I probably understood ~10% of it, but it was certainly educational.

[http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf](http://www.cs.cmu.edu/~rwh/theses/okasaki.pdf)

</comment></comment></comment></comment><comment> T-R This concept is a big part of what the "big deal" around monads is - <USER2> monads to model effectful code conveniently puts the information of "this should be shell code" into the type, in a way that ensures that code that calls it also gets annotated as "shell" code. Monads are of course also a much more broadly applicable abstraction, but their application to effectful code, enforcing this design, is usually the first and most apparent place people run into them in the ML family of languages.

<comment><USER10> Monads is taking it too far. Mutation is a reality, the correct approach is disciplined mutation. Shoving mutation into convenient boxes and convincing yourself to never look inside it does not mean mutation does not exist. The best approach is taken by scheme, and more specifically clojure to have a disciplined and practical approach. Mathematical purity of programs is a myth propagated by Type theorists dont buy into it.

<comment><USER11> I think you misunderstood Monads, or the role type theory has to play in modern programming.

Large projects inevitably benefit from static guarantees enforced automatically by your environment. That can be a 3rd party static code analysis tool or the compiler. Even just a linter will improve code quality and thus developer happiness and productivity.[ _] Having your compiler_ enforce* the functional core/imperative shell, and exposing your business logic _only_ through functional components is what makes a strongly typed language of the ML family stand out over, say Clojure.

Mutating state is no problem in a strongly typed functional language. In Haskell, just put your computation in an ST Monad. You can even still expose a _functional_ signature that doesn't leak the ST monad if your algorithm is faster with mutation.

[*] Overall. Some people will probably be unhappier, because they have to follow "arbitrary" rules now, but those would usually have been the worst offenders.

<comment><USER10> There have been many articles on this topic. There isnt any evidence to suggest that static guarantees makes your code better. Ofcourse what does make your code better is immutability. But complete immutability isnt practical and even Haskell people understand that but they continue to pretend that programs are about mathematical purity. If that isnt enough claiming static typing removes the need for testing is complete bunk.

<comment><USER12> Have you written programs in Haskell/F#/Ocaml? Static guarantees, especially of expressive type systems, absolutely make your code better and their benefits compound as your system gets bigger. The type checker acts as a guardian of the soundness of your whole domain. And yes, expressive static typing removes the need for a whole class of tests, namely the ones that you'd have to write in other languages if you are disciplined enough to care about the soundness of your domain model. I personally loath writing these type of tests but I do when I can't use the power of say Haskell because I care.

Immutability also makes you code better but it's an orthogonal concern and utilising both is a smart move.

<comment><USER10> If it were true, we would all be writing in c++ and there would never be a Stack overflow or Null pointer exception. But thats isnt true.

<comment><USER12> Any language that has null, including C++, does not fall into the category of languages with expressive type systems. As soon as you have proper sum types the null issue goes away + the whole big world of working with ADTs open up.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> So, I am a person who wishes there was a proper article I could read for this. I don't know how much this matters to people, but I can understand written English far far better than I can understand spoken English. I know auto- translate works for some. I am trying with applet and get nothing. I like core idea. I feel often people outside English land get second class experience.

<comment><USER14> People _inside_ English-land get second class experience too. Audio and video are inferior tools for this kind of content, in the same way a linked list is inferior to a vector if you need random access.

In this particular case, I'm annoyed too. I've learned (what I think is exactly) this concept from other sources, and I've been recently linked to this video a couple times. What I would love to do is to quickly diff my existing knowledge with contents of the talk, but I can't do that because it's in a video format. I've been putting off watching it for couple weeks now.

<comment><USER15> I'd say this one (as well as other classics like 'Simple Made Easy') is worth it.

That said, I'd also prefer an article that tells me the same thing.

</comment></comment></comment><comment><USER16> Does anyone know of an example of a non-trivial codebase written in this style?

How do you do this cleanly when, e.g., you need to make a network call and then based on what the result returned to you is, either do something with a local database, make a different network call, or return a result to your user. Also, error handling...

It seems to me like monads must be the logical conclusion to this style of programming, or else you wind up with a mess (or just abandoning this technique.)

<comment><USER17> Literally anything written in Haskell. When you write stateful code in Haskell (such as code that reads from a database, makes a network call, or does IO, to use your examples), that code will be wrapped in a Monad. Thus the type signature of the code shows that it's stateful code, and Haskell's type checker will ensure that any code that calls it also has a stateful type. For example, if a function takes in an `Int` and returns an `Int`, and along the way may _directly or indirectly_ perform IO, that function will have type `Int -> IO Int`.

Now of course, you don't _have_ to cleanly separate a functional core from a stateful shell. But if you don't, all of your code is going to end up wrapped in nested Monads declaring all of the ways that it's inadvertently stateful, and that's a very painful way to program. So Haskell pushes you strongly towards having a functional core and stateful shell.

For projects written in Haskell, the wiki has a long list: [https://wiki.haskell.org/Haskell_in_industry](https://wiki.haskell.org/Haskell_in_industry)

<comment><USER18> I agree, but I think it still takes some coding self-discipline to write code with a functional core and stateful shell in Haskell. There's little stopping you from having every return type wrapped in the IO monad. It's not any more unnatural to do that than it is to code in any imperative language.

<comment><USER17> > It's not any more unnatural to do that than it is to code in any imperative > language.

Yeah, I guess the `do` notation makes it pretty painless. If you start _mixing_ monads, though, things get hairy quickly.

<comment><USER19> Monad Transformers aren't _that_ bad, the MTL style of doing things makes it all pretty painless.

It also provides a huge opportunity for testing. At a very high level, you describe all of your effects as a series of embedded, compostable DSLs that you define interpreters for. The awesome part is that you can switch out the interpreters at will, so you can, for example, replace something that handles network requests with something that returns dummy data almost effortlessly.

<comment><USER17> I think we have different pain thresholds. I would consider this very painful:

[http://hackage.haskell.org/package/transformers-0.5.5.0/docs...](http://hackage.haskell.org/package/transformers-0.5.5.0/docs/Control- Monad-Trans-Class.html#g:7)

> It also provides a huge opportunity for testing. [...]

That's a neat point, thanks for bringing it up.

</comment></comment></comment></comment></comment></comment><comment><USER20> Although it means something different and is not the the actual semantic opposite, I've found the syntactically opposite phrase "Functional shell, imperative core" also useful, which the speaker alludes to when he talks about local variable rebinding that is invisible to the outside.

That is locally scoped, mutation-heavy, imperative code is fine as long as you can wrap it in a deterministic, immutable interface for general use. This is the premise behind things like Haskell's ST type. More generally it's the usual way FP languages try to recover competitive performance.

<comment><USER21> It is also how your computer does basic addition. It isn't like there is such a thing as immutable numbers when it gets to the silicon. Look at how a barrel shifter is implemented someday, or a comparator.

<comment><USER22> It's also how something like React.js works. Wrapping stateful DOM manipulation in a functional shell, made performant thanks to the Virtual DOM diffing algorithm.

</comment></comment></comment><comment><USER23> Often people will ask how to follow these principles in the world of I/O. The answer is incredibly simple: with values.

Return a DTO that encapsulates all the business information about the result state of the I/O call. Do not throw exceptions. Log them if you like, but you must return all the data necessary for the business logic to react to failure conditions, encoded in your own use case specific structure.

If you don't care about whether you failed due to timeouts or refused connections or query parse failures what have you, don't return that data, just return a hasError kind of property on the return structure (bonus points if your language supports discriminated unions, but this is not necessary). If the parent logic needs to react to timeouts and failures to connect differently, then catch those exceptions or state separately and return didTimeout or cantConnect flags separately.

Values values values

<comment><USER24> I would prefer a 'Result<ValueType, ErrorType>' over stuffing weird 'hasError', 'didTimeout', etc flags everywhere.

It's much safer to type-check at compile time that you have discriminated between result and error, than to hope that you are 'if'-checking some flags at the right time at runtime.

<comment><USER23> That is another way to accomplish the same goal. This trade-off is more aesthetic than architectural and is just a matter of language support

</comment></comment></comment><comment><USER25> Great to see this. I ended up writing this way after watching Brian Will's _Why Object Oriented Programming is Bad_ [0]. Near the end he states we should be writing "procedural code" but that we should favor "pure functions". What I took away from this was that at a high level I should be able to reason about a problem procedurally but the solution should be composed of mostly pure functions.

0: [https://www.youtube.com/watch?v=QM1iUe6IofM](https://www.youtube.com/watch?v=QM1iUe6IofM)

</comment><comment><USER23> It's difficult to overstate the importance of the principles taught in this talk. Almost as difficult as it is to describe why they are so important. The fundamentals of quality software are found here, not in some Martin Fowler dissertation on DDD.

Edit: correction from commenter, thanks!

<comment><USER26> I think the general concept of using immutability, queues, and isolating side effects, is lost and muddied by using Ruby, and it's a misuse of the term "functional."

</comment></comment><comment><USER27> In the Idris language, one best practice is to relegate to the outer shell not only IO effects, but also "partiality"—in the sense of computations that might enter an unproductive infinite loop.

(In Haskell, one way of getting into unproductive infinite loops is by mistakenly asking "parse elements until the first failure" to a parser combinator that can always succeed without consuming input.)

The ideal is that the core of the application should be both pure and total, purity and totality being tracked by the type system. In fact, one can often relegate partiality to a single function of the outer shell.

</comment><comment><USER28> This is one of my favorite videos. I highly recommend DAS videos, definitely worth the subscription.

<comment><USER15> Seconded! This one and a few others gave me 'aha moments' that I don't get much without hunting for the right videos (recommendations much appreciated! In the vein of Simple Made Easy).

<comment><USER23> Simple Made Easy should be mandatory watching for your developer's license.

Seriously though, this talk, Boundaries, and Simple Made Easy are the trifecta that forms the foundation of the software I design.

</comment></comment></comment><comment><USER29> This is the same principle of the Clean Architecture. I like how Brandon Rhodes explain how to apply it in Python:

[https://www.youtube.com/watch?v=DJtef410XaM](https://www.youtube.com/watch?v=DJtef410XaM)

</comment><comment><USER30> And I'd strongly recommend paying for DAS and looking at every.single.video in there. Gary is brilliant and each video explains stuff in a very simple, enjoyable way.

Reminds me a bit of Ryan Bate's ruby/rails videos.

</comment><comment><USER31> After watching this and his Boundaries talk, and then reading the Out of the Tar Pit paper, I started watching Pete Hunt's first talks on why they built React and had an epiphany why React was going to end up being the most popular front end framework.

</comment><comment><USER4> One does not need a pure functional core to have benefits of such design. The key idea is that the core code should not change or even read the global state. It should only be allowed to access or change what is explicitly passed to it.

For example, to avoid excessive memory consumption to sum matrixes one wants to code it like A += B, not like C = A + B. Yet one still benefits from all the testing, design etc. benefits of pure functional code. At the end one call always get a functional version just by turning A += B into C = A; C += B.

</comment><comment><USER32> While the purpose of this screencast is to explain a principle, not to focus on the particular piece of software that was implemented, I am left wondering about a couple of things;

The timeline as he explains it, is updated by creating a new timeline instance which consists of previous timeline + new tweets. It seems to me then, that his client does not remove from the timeline tweets that were deleted by its author subsequently to having been downloaded.

To some it might be a feature to capture as many tweets as possible, but at the same time, if your view of the timeline includes deleted tweets then you might find yourself trying to reply to a deleted tweet, and then you would get an error response from Twitter when you try to post your reply. (Though I don't know if his client also does posting, or if it's a read-only client.)

Furthermore, what about tweets that are edited by their author subsequently to having been downloaded? Seems that you would not see those edits.

<comment><USER8> Tweets aren't editable so no need to handle that. Deleted tweets can be honored by updating the timeline to be `old_timeline - deleted_tweets + new_tweets`.

</comment></comment><comment><USER33> How do you implement progress reporting and cancellation in this model?

<comment><USER34> Make it an explicit part of the data model.

<comment><USER33> A quicksort that supported progress reporting and cancellation might have a function parameter that it calls periodically to report progress, with the function returning a bool indicating cancellation. But this is using code, not data.

How might this be implemented within the data model?

<comment><USER35> How do you measure progress in a quicksort?

<comment><USER33> Glad you asked. The progress should be a bound on the worst case time.

If you have N elements, then the initial worst case time is N^2. Say after the first partition, you are left with pieces N/3 and 2N/3; the worst case time is now (N/3)^2 + (2N/3)^2. Your progress after the first partition is the difference between the original worst case and the new worst case.

This can make for uneven progress advancement but it's monotonic: the progress bar will never go backwards.

</comment></comment></comment></comment></comment><comment><USER36> I like to imagine that the huge planet-sized villain from the film The Fifth Element is the physical manifestation of giving one's self over fully to the programming style of indisciminantly mixing side-effectful and I/O operations into arbitrary code whenever it's locally convenient to do so.

</comment><comment><USER37> I'm struggling to apply this model to code for machine learning experiments. The functional core takes an extremely long time to compute, e.g. "train the model". Thus, you want to save lots of intermediate values to disk so you can reload them over and over while you are experimenting the downstream part of the program.

I end up with a lot of code writing values to the disk, which is currently mixed in with the computations. I'm wondering if there's some way to automate this "save intermediate values to the disk" so I can write the code in a more functional style without having to constantly go in and out of the imperative shell portion.

The process of ML experimentation is extremely painful compared to normal software development where nothing really takes that long to compute.

<comment><USER19> The way I would approach this is to write what essentially amounts to a declarative specification of what computation needs to be run, and then define an interpreter that handles the caching of intermediate values.

The "Embedded DSL + Interpreter" pattern is incredibly powerful, and it's nice to see it catching on more.

</comment></comment><comment><USER38> The idea of functional core is cool. I find domain-driven design a better guide for implementation. In a nut shell, there are three types of objects: value, entity, and service. Both value and entity are functional and stateless objects. A service object maps between stateless objects and may cross the domain boundary (such as network, IO, etc). When I do this in java, a service object would have interfaces returning CompletableFuture of Value or Entity objects.

InfoQ has a very nice summary of DDD book: [https://www.infoq.com/minibooks/download/domain-driven- desig...](https://www.infoq.com/minibooks/download/domain-driven-design- quickly)

</comment><comment><USER39> I learned this through Haskell, it enforces the "functional core, imperative shell" approach through the IO monad. Now I find myself repeating the same pattern in other languages(js, java).

</comment><comment><USER38> This is the github repo featured in the video: [https://github.com/bf4/toot](https://github.com/bf4/toot)

</comment><comment><USER40> It's similar to what usually do. Use functional style in inner, smaller, library level code. At the global level, it's unavoidable to deal with state when interfacing with outside. State changes just need to be well encapsulated and managed.

</comment><comment><USER41> This is the pattern I'm striving to code in, but when developing with a team, I keep struggling convincing other people (with OOP, mutability-happy mindsets) to do so...

</comment><comment><USER42> (2012)

</comment><comment><USER26> "Functional core" littered with classes, attr_readers, data that's not data (Curosr.new) and += imperative loops. Yikes.

<comment><USER8> The classes serve to close some functions over variables for convenience; the attr_readers serve as destructuring functions for convenience; the += replaces a recursive function for convenience and familiarity. The function with the += doesn't mutate any value and it remains pure from all callers' perspectives.

You're complaining about syntax, but this screencast is about semantics.

<comment><USER26> No, something with "functional" in the title that doesn't use functions isn't related to syntax.

<comment><USER8> What is a function?</comment></comment></comment></comment>


Ask HN: Productivity tools that need to exist? - <AUTHOR> The landscape of productivity tools is littered with dead bodies. But what else needs to exist? Where are the biggest inefficiencies in your day? Or what would you have a personal assistant do, if you had one? <comment><USER3> I think the reason they're so many dead bodies in this space is that there's not much a productivity tool needs to do, and any attempts to create a new one is just repackaging an existing tool into a nicer UI.

Basecamp is Asana is Evernote is Trello. You have tasks, you assign them to people, and I think 99% of the time the reason people go with a certain tool is the look and feel.

I've found the main driver for productivity (and I know this sounds flippant) is to actually make an effort to be productive. If you aren't making an effort (or your team members aren't making an effort) the tool won't change their behaviour.

<comment><USER4> I find this to be largely true as well. If your team is making an effort, the project management tool's utility is a symptom - it will never be a cause, one way or the other. The only way for me to be productive is to find somewhere relatively quiet (but not silent), get comfortable, and convince myself that working on X is the most productive use of my time right now. Usually opening the editor and firing up the terminal is enough to get me in the swing of things. If playing with whatever I'm working on and finding broken stuff to fix isn't enough to kick-start my brain into problem-solving mode, checking the issue tracker is a good crutch. After the first commit, I can usually start flying. It's all about momentum.

</comment></comment><comment><USER5> Only mildly sarcastically:

I need a natural language robot that can attend meetings for me and produce minutes and an artificial intelligence that can write an executive summary of those minutes, calling out anything should care about.

Alternately, I need a robot attached to the back of my task chair that smacks me upside the head every time my brain segfaults and crashes to reddit.

Alternately, I need a supervisor who doesn't need daily written status updated because we use a task management tool that is worth a shit.

<comment><USER6> Your supervisor wants daily updates because he does not trust the task mgmt tool - quite rightly because I doubt it is linked to the user acceptance and unit test runners and so is no indication of reality. Looking at you and hearing your voice is a better proxy of reality than a gang chart but nothing like tests

As for the NLP of meetings - yes please !!!

</comment></comment><comment><USER6> I just started a contract at a major bank, and have found an area (Dev tooling nothing bank related!) that was missing obvious parts and dove in.

I think productivity is partly good people, good open systems and partly leaving folks to get on and find the biggest pain points whilst not stuffing architecture up.

I think this works for non devs too and has next to nothing to do with productivity tools. I could have been using notepad and a shell and would have done as much useful work.

</comment><comment><USER7> For me is the best important tool password manager. I can't imagine my work without it, it stores all my passwords, fills forms for me and I can focus only on work. Currently I am using Sticky password manager because I don't like to store my personal data to clouds. I am also using Toggl for time tracking because I used to waste my time a lot :) .

</comment><comment><USER8> All of my best projects have been effectively coordinated over email - <USER2> other productivity tool involved. In my experience, if a small, nimble team can't effectively coordinate over email - any tool will only exaggerate their problem.

</comment><comment><USER9> I'm looking for a simple team task management tool (I like Flow) for the terminal. Or better: One that works like Flow, but has both a GUI and a CLI.

</comment><comment><USER10> I'd like a good dashboard for my life.

</comment><comment><AUTHOR> The comments are all great. And I appreciate them. But I suppose I'm most curious about the last question: what would you have a personal assistant do, if you had one?

<comment><USER11> I would have them handle all my email and attend time-wasting and useless meetings.

</comment></comment><comment><USER12> A new Gmail.</comment>


Ask HN: How'd you start your business outside of tech? How did it turn out? - <AUTHOR> The tech industry seems to have a lot of gravity in my life and it's difficult to leave it. I've been a developer for a bit over ten years, and while I genuinely enjoy development in many ways, I've stopped feeling like I have much to bring to it or get from it and I've decided I'd like to pursue a business idea instead. Programming and other past career experience will complement it well.
I've looked at some local resources for how to determine viability, potential market, figure out what my cash flow will look like, etc. and everything looks fine for the most part. This research wasn't too hard to do, but I'm also curious about how people make this transition on a personal as well as professional level.
It feels as though leaving development is like throwing away 'easy' money. At the moment I can be compensated reliably well for my skills. It's hard to walk away from that. It's also hard to walk away from knowing I can definitely have a positive cash flow.
Another hurdle is that this endeavour wouldn't produce much income for around 2 years. I can speed that up a bit and soften that financial hit by taking out a loan, but I'm in a spot where borrowing isn't necessarily essential and I'm very averse to taking on debt. But what are your perspectives on loans vs investment?
Without outside financial assistance, I think I'd need to continue programming until my business found traction. Are there feasible ways to do that though? I wouldn't be able to be an involved member of a team, but I would be able to do good work remotely and independently. Have any of you found contracting opportunities suiting to that situation?
I'd love to hear some stories of others making this transition, what kinds of businesses you started, and how you managed the transition - any kinds of details would be welcome and interesting. <comment><USER2> I think if you want to create a business you should forget this tech compensation of whatever. If you don't enjoy tech that much and feel bored, what good does it brings if you make $200k in tech or $40k being a restaurant owner?

The most important thing I would care is if I'm enjoying that more than working in tech. Remember you will die one day and most of the people can actually get by with very little, much little even than $40k. As you only live once, chose what you want to do with your time based that YOLO, not on some number of moneys.

If you are making the business with the sole reason of being richer after X years than you would if you would be working in tech, I think it's very,very,very likely you will fail

<comment><AUTHOR> This all resonates with me. I appreciate it. I have no illusions of getting rich at all - the work I want to do is not particularly lucrative, especially at lower scales. It does however involve a lot of disciplines I'm passionate about, produces a product I'm passionate about, and would likely keep me engaged or even engrossed for a very long time. It would also be positive for my community. What I do now is not these things.

I agree especially that you really don't need that much to get by. I've been a main or sole provider to a family for a while though so it's hard to shake the urge to earn more. I find that attitude very toxic at times though... Money hasn't done much to improve my life in meaningful ways for a long time now. Over time I think I'll adjust to earning less just fine, so long as everything and everyone is taken care of.

Thanks very much for the input.

<comment><USER2> No problem, maybe one of the biggest challenges you will have(I see me having that at some point as well), is to remind yourself why you are doing what you are doing and why it matters. Make some posters, reminders etc?

<comment><AUTHOR> Good point. I can see running a business being difficult when reflecting on an easy salary behind a desk...

</comment></comment></comment></comment><comment><USER3> > Without outside financial assistance, I think I'd need to continue > programming until my business found traction. Are there feasible ways to do > that though?

I haven't tried to start a business. But another option to contract work is to find a part time dev job. Some employers are happy to have you there 3 days a week in a permanent role. Not too rare for parents with young children.

That said, an employer might be a bit less excited about bringing you on part time if you were open about your plan to go full time on your own business in a couple if years of things went to plan.

<comment><AUTHOR> That's actually my situation exactly (3 young kids), and a part time role would be ideal. Especially now as I'm transitioning into being a single parent. I'm anticipating this change occurring on the scale of 2 years+ rather than months though, so I don't think it would be an issue for potential employers. I would likely be around for the average stay of an employee in tech.

I wasn't aware that's a common arrangement though, so thanks for that. I'll start looking for those opportunities as well, or asking about the opportunity during interviews.</comment></comment>


Android app startup time: why we care - <AUTHOR> https://medium.com/inlocotech/android-app-startup-time-why-we-care-b70eada84b26 <comment><USER2> Really helpfull!</comment>


Wikipeida game - <AUTHOR> http://wikirace.singleusermode.com/

<comment><USER2> Awesome. I went from:

Physical exercise->Physical fitness->Federal government of the United States->United States->List of countries and dependencies by area->Italy->Mona Lisa

<comment><AUTHOR> Good job on the Białasowizna -> Indian mackerel; I was cheering ya on from the logs perspective.</comment></comment>


Why Frameworks Suck - <AUTHOR> http://term.ie/devdev/why_frameworks_suck <comment><USER2> This article craves for a global search & replace operation:

"framework" --> "monolithic framework"

I think a good framework should be developed as librairies each solving a particular problem, glued together. Of course, at first you'll probably have many things in core that don't really belong there but there must come a time where you refactor to separate functionnality into distinct librairies (that you can use without the framework!). The "vertical" integration is done by glueing the librairies that were developed alongside it in a coherent whole.

And I think frameworks should recommend approaches, not dictate them. For example, I'm fine with a framework that provides an authentication system out of the box, but it should be integrated as a normal plugin so that anyone can write a competing, alternative authentication system.

In other words, explode your framework in tiny pieces and then glue those together.

edit: I think that would be a boon for the adoption of a framework. People first start using some of your librairies, and over time they use more and more of your librairies and at some point they simply adopt the whole framework.

<comment><USER3> That's mostly a semantic game you're playing. What you term "monolithic framework" is what the author (and, IMHO, most developers) mean by the term "framework". The rest of your post describes what most people are happy to call a "library" or "toolkit", or "utility".

Frameworks, as understood by common industry terminology, are defined by providing the vertical integration you are talking about.

<comment><USER2> If when people talk about "frameworks" they're really talking about "monolithic frameworks", then maybe most frameworks indeed suck, because they're all guilty of the accusations made in the article (which amounts to: monolithism).

Imagine some monolithic framework. Now, a Super Magical Refactoring(tm) takes place and the public interface doesn't barely change at all, everything is the same except that the core is made tiny and almost all the functionnality is implemented as libraries that were extracted from the previous core but obviously fit perfectly well with the core and eachother.

You're telling me the framework is no longer a "framework" but just a "library"?! I think _you're_ playing semantic games.

I say modularity doesn't preclude "verticalisation".

</comment></comment></comment><comment><USER4> On the contrary, I've found that picking up an application written in Rails by someone else is quite easy. Far from building walls between developers, I think a good framework like Rails encourages communication.

Daniel

<comment><USER5> <http://ycombinator.com/newsguidelines.html>

</comment></comment><comment><USER6> I can understand his point, but that only applies to _other people's_ frameworks. There's nothing quite like working in a framework you designed for yourself.

</comment><comment><USER7> For web development once a site gets beyond the basics I find working without a framework to lead to a confusing and unruly codebase that is often a frustration to work with.

Your framework need not be rails, django, or cake for it to be useful.

</comment><comment><USER8> Many people don't want the full blank canvas to start with. They like having specific direction as to what parts of the application go where. For then, frameworks work well.

Judging from what people did with Flash and are doing with Flex, I think with many people a blank canvas is an invitation to do really stupid stuff.

So as always it's a people issue and not a technology issue.

</comment><comment><USER9> Coming next: why some other stuff I don't use is really sucky, and everyone who uses it isn't a Real Programmer.

</comment><comment><USER10> Obviously, frameworks have some measure of utility, being that so many people use them. Though you give multiple reasons why a person might not use a framework, you neglect the good points that are obviously making people use them.

"Frameworks suck because they are an avatar of enterprise, frameworks suck because they take away your freedom, frameworks suck because they build walls between coders, frameworks suck because they make you fit your project to the toolset rather than the toolset to the project, and frameworks suck because they take the fun out of programming, long live the library."

Please answer this: why DO people use frameworks?

<comment><USER3> Because it's easier at the beginning. Doing a big application from scratch requires doing stuff like requirements analysis, which means you need to understand the universe of tools available to make good decisions. Then you need to prototype for a while before settling on the final design (i.e. your custom framework).

With rails (or whatever) you get something that works immediately, which feels safer to a lot of folks who don't have the deep toolkit expertise required above. The problem is that while the framework _works_ , you don't actually understand it any better than you do the toolkits, it's just handling stuff for you with (what you understand as) voodoo. So when it comes time to make big design changes in the future, the toolkit folks know exactly where to start, while the framework people are completely lost.

I'm not completely against frameworks, but I've seen _so_ many misused that I'm very wary. A stupidly-applied library is usually a point-source bug that can be fixed in one place. A stupidly-applied framework infects the whole application with its mess.</comment></comment>


Ask HN: What are the repercussions for lying about competing offers? - <AUTHOR> <comment><USER2> It depends on the cost it takes to make the claim. [https://en.wikipedia.org/wiki/Signalling_theory#Dishonest_si...](https://en.wikipedia.org/wiki/Signalling_theory#Dishonest_signals)</comment>


Justin Trudeau Announces the Queen's Approval of Canada's Next Governor General - <AUTHOR> http://pm.gc.ca/eng/news/2017/07/13/prime-minister-trudeau-announces-queens-approval-canadas-next-governor-general <comment><USER2> Isn't it 2017 already? Make drop the whole royals thing?</comment>


Ask HN: Examples of great concept pitches? Advice? - <AUTHOR>

I'm making a pitch for a concept competition in two days. Working on the presentation now. Are there any good examples of concept pitches that I can learn from?<p>Background: it's a college competition with $40,000 at the end. We're very excited to be in the semi-final round and at the stage where we actually get to present (in person) our idea. <comment><USER2> Some general rules here to make your pitch more appealing:

<http://en.wikipedia.org/wiki/Made_to_Stick>

<comment><USER3> How not to suck at a group presentation:

[http://www.bothsidesofthetable.com/2010/01/31/how-to-not- suc...](http://www.bothsidesofthetable.com/2010/01/31/how-to-not-suck-at-a- group-presentation/)

</comment></comment><comment><USER4> Best way to pitch a concept is to build a prototype. Design it in Photoshop.

<comment><AUTHOR> While I certainly understand the merits of having a prototype, the competition is structured to focus on concepts (we don't have a lot of time to prepare).

If we were to build a prototype we would want it to be really awesome, which isn't too realistic right now.</comment></comment>


Twitter Rolls Out New Web Design That Aligns With Mobile Interfaces - <AUTHOR> http://techcrunch.com/2014/01/13/twitter-rolls-out-new-web-design-that-eliminates-pop-up-composer-aligns-with-mobile-interfaces/

<comment><USER2> Web design just stepped up its game to the levels of fashion. I mean, in terms of not making sense.

</comment><comment><USER3> It hurts my eyes</comment>


Do Office Workers Compensate for a Lack of Visual Access to the Outdoors? - <AUTHOR> http://eab.sagepub.com/content/early/2011/01/12/0013916510368351.abstract?papetoc

<comment><USER2> I depends on how hot they are.</comment>