Show HN: I wrote a book for engineers that want to become engineering managers - <AUTHOR> Hey folks.
Last year I was fortunate enough to sign a deal to write a book with my favorite technical publisher, The Pragmatic Bookshelf.
When I started out as an Engineering Manager many years ago, I found that there wasn't a huge amount of material that specifically and practically helped me understand how to do my job. When you learn to program there's all of these amazing tutorials, examples and guides, but what was there for new managers?
In response to this, a couple of years ago I started a blog over at https://www.theengineeringmanager.com which got a decent amount of traction - I had a few front-pages here too, which was awesome. I improved a lot as a writer.
This gave me the confidence to pitch a book to numerous publishers and thankfully my ideal choice wanted to work with me.
The book has now been released in beta, which means you get DRM-free access to the first 240 pages (13 chapters) and more chapters will be pushed out as they get finished. I've written 17 out of 19 of them so far. The hard copy should be out in the Spring.
It's available with free excerpts here: https://pragprog.com/book/jsengman/become-an-effective-softw...
If anyone's at all interested in learning about what it's like to pitch a publisher with their own book idea, then I guess I've been successful at that now, so I'm more than happy to give you any advice. I've had a great time working with PragProg and my editor and the other staff there have been (honestly) fantastic.
I'd love to hear your feedback, and the nice part about the beta process is that the book still isn't finished, so there's plenty of scope for improvements.
Thanks all! <comment><USER3> IMO being a good engineering manager is quite subjective and varies across companies and even teams. The traits of a good engineer would roughly be the same across companies and would be ranked according to knowledge, work experience and quality of code etc. And since a software engineer reports to an engineering manager, expectations are also based on the views of one person.

Upper management in different companies would have different expectations from what an engineering manager should be. Some would want them to code, some wouldn't. Some would want them to utilize developers as much as possible while some would want them to keep work life balance of developers in mind. Same with teams. A much younger team would have vastly different views on what a good manager is compared to a team which is filled up of more senior people. A younger team might want the EM to be more hands-on while a senior team would want more autonomy. Then you also have HR and feedback from various teams to deal with. Company culture and popular managers would also drive some of the traits of an engineering manager.

Having been an EM for multiple teams I've had to change my management style multiple times to better suit change in higher management and different teams. But I've always been appaled by how less content exists for learning about engineering management. Nice to see someone focus on this area!

<comment><USER4> I agree this is true of engineering managers but its also true of engineers.

Some organizations want them to engage with end users and do a lot of business analysis others want them to focus on coding.

Some organizations want engineers to follow protocol and coding guidelines to the tee. Other want you to make the right call for the circumstances.

Some organizations don't care how long something takes but want it to work perfectly. Others want to make sure you deliver a product on time even if it's buggy.

Some organizations expect you to always choose the right language/tool for the job, some want you to choose the organizational language/tool everyone is familiar with.

I'm a consultant and sometimes run into this issue. Building out an MVP for a start up is a completely different mindset than working on a fortune 500 Enterprise app.

<comment><USER5> Same for product managers as well, ranging from technical customer support agents at enterprise fortune 500s to app developers at small startups.

</comment></comment></comment><comment><USER6> Congratulations on getting published!

I've bought the book and read until the Delegation chapter.

Up until now I find that the topics are interesting and the writing is very direct and unpretentious which I appreciate.

I also like the approach you took of wrapping it in a story, I think it makes the topic a lot less dry.

At the same time I feel that it doesn't go into the detail I would like.

For instance I feel that the "How to Measure Your Output as a Manager" is a bit hand waved by using Andy Grove's equation. This is a topic I struggle with because I sometimes feel that I don't produce anything as a manager and that is frustrating.

Nonetheless, the chapters I've read are fine as a starting point and appreciate that you suggest additional literature to deepen the topics.

Overall I'm positive about the book, would buy again :)

<comment><AUTHOR> That's kind of you to say that! Thank you. Can I email you to get some more of your feedback? What's the best way to contact you?

<comment><USER6> Hi, sure, check my profile for my email.

</comment></comment></comment><comment><USER7> If anyone is considering moving into engineering management, you'd do well to look not just at the _how_ but the _why_. If it's for status/salary rather than the change in nature of the work be very careful about making the move.

You need to really _want_ to manage and develop people (with all the idiosyncracies that real human beings come with!), and to communicate, co- ordinate, and delegate for a living.

Some will love this, others hate it. But don't view it as a natural progression that will work for everyone.

<comment><USER8> Who cares that much about the salary when you are that point in the Software Engineeering career track in SV anyway? What, really, is the difference between making $300K/yr and even fully doubling that to $600K? A nicer apartment, a nicer car, an earlier retirement? These are pretty marginal things if the cost is spending most of your time doing something you don't like.

The most common reason somebody becomes an EM that I've observed is because somebody else tells them to do it. It's a promotion, so you should want it. I'm one of very few people in the SwE world I've encountered who very actively and clearly wants to do it, and for the reasons you listed - to spend more time on humans and less on code.

Most of my managers have at best tolerated the position; several have confessed being miserable and just wanting to code again ("okay, let's switch" hasn't worked, though). That includes my current and previous manager; the one before those 2 said he didn't want to manage and despite being CTO was trying to maneuver into more of an architect position, the one before _that_ quit within a month of being promoted. I've known several people who were EMs and switched back, and had a friend confess that she was on the verge of quitting before she got offered the chance to be an IC again.

Not a one who got promoted and then loved it.

Given that it's true most ICs want to code and not manage (even if many can learn to be good managers), and these days big company ICs are very well compensated... it really feels like the driving force is external - <USER2> else tells them to do it, it looks like the natural progression, and that's "just what you do" more than anything else.

<comment><USER9> Very spot on observation. I'm currently on the 'I tolerate it' bucket but I'm actively trying to hire for my replacement so I can move back to being an IC again.

At first I really disliked it but the more time I spend doing it, the better I get at it, the more rewarding it becomes. I fear by the time I find someone to actually replace me, I won't want to go back to being an IC.

<comment><USER5> It's an entirely different job, that's why nobody can just drop into it from being an engineer and magically be good at it.

Very few of the skills overlap even within the same categories such as architecture and execution. One is about the code, the other one is about the people.

Once the core skills are developed e.g. being able to clearly communicate a vision and plan, ability to have tough conversations, building interpersonal trust, being an effective salesperson for the team. Once these skills are adequately developed, it becomes a good job again.

Most people have spent at least a few years training to become a professional software engineer before being able to do that job, and yet most engineers don't give themselves/others the same understanding for developing the necessary skills to become a professional engineering manager.

</comment></comment></comment></comment><comment><USER8> Does the book cover how to get the position in the first place? I've read countless books (Like "The Managers Path" and "Managing Humans"), blog articles, etc, and tried many strategies, but it never seems to happen. Usually for the catch-22 reason of not having managing experience.

I've even had past managers they had no worries about me having the skills or knowledge to do it... but it still doesn't happen.

<comment><USER10> The tactic that worked for me was to bring it up to my boss. I set up a 1:1 with him, and said "In 2-3 years, I want your job. How can I get there?" (and "want your job" obviously means "to do what you do" not literally take their job)

If you have a good manager, they'll set you up for success, working with you to create a roadmap to get from IC to Manager. The steps in between would probably entail taking on larger projects, mentoring others, leading a project with multiple developers on it, and then after demonstrating all of that, you get the promotion.

In my experience, you get the promotion when you're already doing the job. In other words, you do the work and the promotion is recognition of the work you're already doing.

The other thing I'd say is that you don't get what you don't ask for. If you want to be a manager, ask for it. If you want more responsibility, ask for it. If you want better compensation or a new title, ask for it.

Unless you have a FANTASTIC manager, you will never just magically be recognized for your work. They will assume you're happy doing what you're doing and focus on greasing the squeaky wheel. To further your career, you should be a little squeaky. Ask for what you want. If you can't get it now, ask for help getting to that point.

I, as a manager, really appreciate it when someone gives me direction on what they want. Otherwise, I have to guess or try to pull it out of them, and I feel like I'm pulling teeth. It's hugely beneficial for a manager to have proactive direct reports. Be that person.

Good luck.

<comment><USER11> Just wanted to second this. As a manager, even for people I know fairly well, I'm routinely surprised by little bits I learn as to what they want, what they dislike, or what gets them upset. Do not assume your manager can read your mind or that things are self evident and universal. With people, most things arent. Not much different than any relationship.

<comment><USER12> Just wanted to second your comment. I'm continually surprised at the number of individual contributors who (1) expect their manager to be perfect even though (s)he's a human; (2) expect immediate gratification of their needs; (3) are only too happy to push all decision-making to the manager; (4) don't realize that the mgr can be having a bad day; (5) compare their mgr to a friend's mgr without comparing the job conditions; etc (not that a manager shouldn't strive towards perfection).

OTOH, I'm also surprised by the number of managers who (1) implement something because "my friend at <massively successful co> uses <tool/process etc>; (2) don't understand that their colleagues have lives outside work; (3) don't realize that they're being partial to some folks; (4) take advantage of the "meek" contributors; (5) don't protect their team from upper mgmt when needed; (6) don't do the grunt work when needed (and it's always needed) etc.

In other words, just like any relationship, as you say.

</comment></comment></comment></comment><comment><USER13> Looks very interesting! Can you also write one about how to go back to engineer from engineering manager? :)

<comment><USER14> I just recently did this in my company and have been mulling over giving a talk about it.

<comment><AUTHOR> You should! I think there's a lot of stigma around it. It's definitely not a step "down".

</comment></comment></comment><comment><USER15> Congrats on the book. Have you ever explored alternative forms of management and organizational forms? Stuff like Sociocracy, Teal (from Reinventing Organizations) or management as envisioned by Deming. I wonder whether the engineering manager role as usually interpreted isn't really an anti-pattern, I mean we're basically applying Taylorism to knowledge work.

<comment><AUTHOR> Thank you! I haven't gone into detail about these in the book. This is very much the standard Engineering Manager route that people would find in most places in industry right now.

However - if you don't mind - I would love to use those as examples in the final chapters where I mention the opportunities offered by moving into start- ups, and also where our managers will be given more autonomy to set the culture of a wider organization (of which that culture could involve much looser management structures).

Great pointers, thank you.

<comment><USER15> Cool! I actually work at a company that adopted Holacracy roughly 3 years ago. In many ways it's probably much less loose and more formal than most people think (I mean there is a written constitution written in Legalese).

There are still roles that resemble the classical management role, i.e. there is a role that is responsible for setting strategies and assigning people into roles and monitoring role fit within their 'circle' (think team or business unit), called the circle's lead link. Yet there is a process for any role holder to propose putting those accountabilities into a new role or into a process. Role holders can also propose the creation of new roles or policies if they feel a tension. Then there is a structured process to deal with these proposals, and people need to demonstrate that the proposal would cause harm and reduce the capacity for the circle to achieve its purpose in order to have a valid objection. People in roles ultimately have ultimate autonomy on how they want to achieve their role's purpose. The lead link role can give relative prioritization if there are conflicts, but the lead link can't say 'you have to work on this right now and this is how you gonna do it'.

What ultimately happens is that the traditional accountabilities of a manger end up being distributed across multiple roles, so people might have software developer role, but might also be responsible for defining the hiring standards, or do people development etc.

It's kinda similar to the book "Turn the Ship around" where you don't have to ask for permission to do something and there is a process to address any tensions that arise from this power to act autonomously.

<comment><AUTHOR> This is fascinating, thanks! Turn The Ship Around is on my reading list.

</comment></comment></comment></comment><comment><USER16> I transitioned from software engineer to engineering management 2 years ago. It was by far the most challenging (still rewarding) moment of my career. I was lucky to have the opportunity to build up a team from scratch to take over the services and architecture I designed, developed and operated.

Biggest lesson learned: you're no longer the decision-maker on your technical stack. Your team is responsible. Still, you're liable for the result and its impact on business. That duality is hard to reconcile for former engineer. The solution? Build a culture. Better: create the conditions for a sustainable culture to emerge and persist.

That insight, and many other advices for new managers are compiled at: [https://github.com/kdeldycke/awesome- management](https://github.com/kdeldycke/awesome-management)

</comment><comment><USER17> I don't know whether it's in the book - perhaps it's in the " _How to Win Friends and Influence People_ " chapter - but one thing I struggle with is communicating outwards and upwards.

I tend to assume that everybody else in the company knows that my team works in the way it does because that's how you deliver software successfully. Often, this comes back to bite when I learn that other managers think the team should be managed differently, and because I haven't made enough efforts to sell our methodology, those managers can have more influence than I'd like.

So, as an Engineering Manager, it's not enough that everybody in your team is happy and produce. You also have to be an advocate for your team to the rest of the company.

<comment><AUTHOR> I totally agree on your final sentence there. There's a number of things in that chapter you mention, and there's also material on managing upwards earlier on in the book.

As an example of something I personally struggle with: what's the best way to have the rest of the company know what all of our teams are working on without A) going into too much detail B) being obtuse C) opening ourselves up for miscommunication to customers or deadline promises D) giving ourselves room to fail, because not everything will work out.

The current iteration is a fortnightly newsletter that I curate between product and the engineering managers in the department and it gets sent around, but making everyone happy with it is /so/ hard.

<comment><USER17> You really hit the nail on the head there. It's so hard to give the right people the right information at the right time.

I like the idea of the newsletter. Do you focus mostly on achievements, or discuss 'ways of working' as well?

I'm really looking forward to the book, by the way.

<comment><AUTHOR> Thank you!

The target audience for the newsletter was decided as "the busy exec". Not too much text, lots of gifs of functionality that we've built, etc.

There's some separate newsletters we do as well - there's a fortnightly "what's going on in the backend" one, curated by our infrastructure teams that's aimed at engineers.

Currently the general case newsletter goes to Engineering, Product, Product Design, and the exec group. We don't think it's quite good enough for the staff@ mailing list yet, but maybe we're just being over-cautious. It's really hard to get the balance right.

<comment><USER18> Gifs? Don't low quality animations make it hard to read?

<comment><AUTHOR> When they're embedded in a Google Doc, they're pretty good at getting the point across - then they can have a link to the app itself too.

</comment></comment></comment></comment></comment></comment><comment><USER19> Warning ... cynical, pessimistic viewpoint coming.

Here is a pattern that I've observed over a few jobs that I've held as a developer at different companies. Wondering if anyone has any similar experience.

The first line manager (only manages individual contributors) exhibits these characteristics.

1.)He used to be a coder, but that was a long time ago. SQL hasn't changed, so that's the bit he's drawn to when he feels like he needs to roll up his sleeves and contribute.

2.)He has some form of attention deficit, demonstrated by the fact that he can't hold down a conversation really well. Especially if it gets technical.

3.)He really overplays the busy body persona. Always checking phone, always late for a meeting.

4.)He's really insecure in his position within the company, always fearful that he's going to be cut loose. This is extremely amplified when he gets a new manager himself.

5.)He has very little influence over direction. He's really just a proxy mouthpiece for higher level management. And he loves to have status update meetings where he informs the team of all the important updates he received in the big important meeting he attended with other big important people.

6.)Instead of being someone who is respected by the team, he becomes more of someone you have sympathy for.

7.)You wonder why he never asks the real questions, like "are you happy with your role?". And you realize it's because he doesn't really want to hear the answer. He couldn't really do anything about it anyway. See point #5.

8.) He's way too preoccupied worrying about his own safety to nurture the team.

9.) As a developer, you have the safety net of knowing that in the worst case scenario (terminated) you could find another job fairly quickly with pay parody. As a manager, you don't have that comfort blanket. So you cling on to your current job no matter how badly you are abused. And people lose more respect for you because you look pathetic without a backbone.

10.) As a cynical developer in his 40's, you realize that you don't observe many 50+ developers in the wild, and you bemoan the idea that you're going to have to suck it up and play manager eventually.

Anxiety and existential crisis is built into the tech career trajectory, and I feel like the only winning strategy is to be ok with moving backward income wise at various points in your timeline.

<comment><USER20> Without commenting on the specifics on your comment: what does this have to do with the OP's book? If anything, writing a book with ideas, experiences, and techniques aimed at helping people be better at this job is responsive to all the problems you identify.

<comment><USER19> Just commentary on the engineer turned manager narrative. Please forgive if it is out of place. Should I delete it?

<comment><USER20> Nah sorry for calling you out like that, it's slightly off topic but a fine rant. For what it's worth, I agree with many of your points, but hope we can do better as the profession continues to mature.

</comment></comment></comment></comment><comment><USER21> Hey I made an app to help me be a better engineering manager, I'd love your opinion on it if you had some time.

[https://apps.apple.com/us/app/team- lead/id1466421445?mt=8](https://apps.apple.com/us/app/team- lead/id1466421445?mt=8)

[https://play.google.com/store/apps/details?id=co.jmoses.manu...](https://play.google.com/store/apps/details?id=co.jmoses.manus.play)

</comment><comment><USER22> > If anyone's at all interested in learning about what it's like to pitch a > publisher with their own book idea, then I guess I've been successful at > that now, so I'm more than happy to give you any advice.

Maybe this needs to be a new book?

Seriously, all of this sounds wonderful - and thank you (but I would love to hear some tips on getting a book published from zero - I certainly write enough that I could probably fill a book, whether anyone would read it though...???).

<comment><USER23> I'd love to hear more about this as well.

</comment></comment><comment><USER24> Make sure to buy two copies so you can read it twice as fast

<comment><USER25> I'm buying 6! I'll be CTO by the end of the month!

<comment><AUTHOR> Oh no, these people know the secret!

</comment></comment></comment><comment><USER26> This looks interesting. I assume that this is very us-centric though? Have you gotten any international reactions/feedback during writing? I guess it's har to say but how applicable would this be in other parts of the engineering world? I've only worked in tech in Sweden and I sometimes feel like that "it's pretty much the same" but other times: "us tech scene is aliens on another planet".

<comment><AUTHOR> That's a good question. I'm English and I work for a UK company. I had some reviewers at the 50% stage who were from European companies and they didn't say anything specific about this, but I'd be interested to learn more about the US tech scene being quite alien - I haven't experienced it myself.

<comment><USER26> Well, I guess I assumed wrong then! =)

And for me as a Swede the most alien thing for me is the "lone genius startup"-thing (that probably is very over represented/emphasized here at HN) where developers work for stocks(?) and hope(?) that the company will blow up and seem to take great personal risks. Of course that exists here as well in small startups but we have so strong work force-regulations that I don't think it can get that extreme. And now that I think of it it might be that we are the odd ones so maybe it's not so much u.s. vs. e.u. as u.s. vs sweden. ¯\\_(ツ)_/¯

<comment><AUTHOR> I understand. Yeah, we're a VC-backed company but it didn't feel like the journey was a movie script at any point.

</comment></comment></comment></comment><comment> vi-mode OT: for those who have never been in leader/managerial positions:

\- Leading people is 1000x less fun than coding

\- Leading people makes your more money than as an avg coder

\- Leading people too long makes you lose your technical skills slowly

\- At some age and for most, there's no other option than leading, 'go or grow'

\- Leading bigger headcounts is comparable to competitive sports 24/7 and shouldn't be underestimated

<comment><USER27> 1000x less fun? That's extremely subjective, and depends enormously on what you draw satisfaction from. Leading people can be a lot of fun if you genuinely care about the people you are leading and take joy from empowering and enabling them to grow and succeed.

<comment> vi-mode Yes and no. You can move mountains with good teams, this is great and you will draw satisfaction from. But IDK if you had ever 100+ people in your reporting line for a longer time. Then you knew that it's everything BUT definitely not _a lot of fun_. It's super hard work and will push you and your mind dangerously to the limit.

<comment><USER28> It's a different mindset, but I still think it's fun. For me, the key with that size of a group was focusing on the development of the leaders under me. When I make sure they are set up for success, things go smoothly.

The hardest time in my life was trying to micromanage a large group. Once you let go, and focus on the bigger picture, it's quite fun. Challenging, for sure, but very fun.

<comment> vi-mode Hint: you should never frame your reports in such a way ('leaders _under_ me'), 101 of leadership; but let's move on: I think we are not talking about the same; managing people has no short-term feedback loops like coding, it can be fun yes but many confuse this fun with the status involved; from a rational perspective and with the experience of heading larger headcounts (did you lead 100+ teams for a longer time?) paired with hitting ambitious org goals, I find it hard to call 'managing people' fun.

<comment><USER29> What is the proper way to frame reports? "leaders reporting to me", "managers I manage"?

<comment><USER28> DNA evidence works well.

In all seriousness, I recommend not referring to them as "reports" at all. Call them "My Team", "us", "we". It creates a sense of collective ownership.

When talking up, I use specific names, or "the team" to reference tasks or successes, and "I" when we talk about failures. I own what goes wrong, they own what goes right.

<comment> vi-mode Hm, how should this work? If I'd ask you, 'How many direct reports do you have', what would you say? You need to use the term 'direct report' again.

If you fuzzed around with 'my team' while I try to understand you team structure, your direct report count, their profile, which and how many reports they again have, you'd drive me nuts with a fake 'my team' humbleness.

Using the term 'report' is absolutely ok, you shouldn't talk all day long of your reports of course or trying to impressive anyone.

<comment><USER28> You seem to be taking something about this thread very personally. I'm sorry for that. I hope you have a good day.

<comment> vi-mode You think so? I just disagreed with the things you wrote because I think some of your statements are wrong and/or mislead and they're altogether also inconsistent.

<comment><USER28> I don't believe they are inconsistent, but I also have the advantage of knowing my own life intimately. I suppose the context makes a difference.

There are very few "rules" in this game, so feel free to manage differently. You have 100+ on your team, so I'm sure your methods worked well for you, as mine have for me.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER30> Congratulations on getting as far as you have.

I look forward to reading this, I've been making this transition so I'm sure plenty will relate to me.

A couple of points :

Is there anywhere I can pay for this in pounds?

Your choice of excerpts is very teasing, but I haven't had a chance to read any of the in depth content. Would you consider one of the sub-sections? That said, I suppose they did work for me... So maybe you know what you're doing!

<comment><AUTHOR> Hey! I think you'll have to wait until the thing is done and then you can buy it from Amazon and other bookstores. Couple of months, I guess.

The publisher is in charge of choosing the excerpts, but I'll feed that back to them.

</comment></comment><comment><USER31> I've been looking for something like this. Hope it's good.

One thing: the description starts with "Software startups make global headlines every day". That line seems completely disconnected from the rest of the description and it seems nothing would be lacking if you started with the next sentence instead.

<comment><AUTHOR> Sure, that's good feedback and makes a lot of sense. I can edit that blurb.

</comment></comment><comment><USER32> A competent manager is a very rare breed indeed. Competent team leads - I've had a few of those. But at any level higher than that all competence seems to fall away. Success would seem to be despite management rather than because of it.

</comment><comment><USER33> Do you also deal with the 'why' of moving to the management track? I've seen quite a few people becoming depressed and moving back from the mgmt track to their old position.

<comment><AUTHOR> I said something similar in another comment, but one of the things I say in the introduction is that I've written the book to help people understand what the management track is really about. So if someone reads the book and decides that it isn't for them, I think that I can hopefully say I've helped them also.

</comment></comment><comment><USER34> I had written such a book too, but in Chinese, you can find it here if you are interested:

[https://afoo.me/books.html](https://afoo.me/books.html)

</comment><comment><USER35> This looks great and I would love to get one. I am interested in the Hard Copy only (I can't do ebooks). Is there a mailing list for the hard copy ?

<comment><AUTHOR> Sure! Sign up here: [https://t.co/burXhyiuoK?amp=1](https://t.co/burXhyiuoK?amp=1)

</comment></comment><comment><USER36> Well done, this is an area that could use more declarative information and less guesswork. I think there's another question that also needs answering: how do I make myself _want_ to be a manager? A lot of times, the incentives tell the engineer not to bother because the money is already good and you have a decent impact anyway. I'm very interested to hear your thoughts on the subject.

<comment><AUTHOR> That's a very good question. In the introduction I've said that I've written the book as a way of letting people understand what the role is really like so they can make that decision.

However, I think that I could use a sidebar to the reader to allow them to further question their own motives, and help them make that decision more clearly.

</comment></comment><comment><USER37> I will keep in on your book. I've read the "Effective Manager" and the "Manager's Path" so far. The first one has some good hints here and there but it's overly verbose and at times feels like a marketing campaign. The second one, I loved and resonates with my experience so far.

Congrats for getting published!

<comment><AUTHOR> Thank you! I hope you like it.

</comment></comment><comment><USER38> In most big companies in Silicon valley, being a manager is not a promotion but rather a parallel track.

What I find strange is that most of big cos expect managers to not be technical anymore. There is that weird expectation that the manager should have been technical in the past but is now only used as an enabler for the team.

<comment><USER39> Even in silicon valley this is largely the minority. Yes it does occur more frequently here but not to any scale worth noting.

It is part of human nature for leads to gain more than the fair share even when the leads are doing disproportionally less work and less skilled work. This has happened across the board for almost every culture past tribal cultures.

</comment></comment><comment><USER40> Are there alternative methods on buying your book? I don't have PayPal and I don't have a credit card.

<comment><AUTHOR> Good question! I don't know. I can ask my editor. When the print copy is out it will be available from bookshops and Amazon and so on, so maybe that's the short-term answer.

</comment></comment><comment><USER41> As someone who's constantly at somewhat of a crossroads on the subject, this book's intro leads me to believe it's exactly up my tree. However, I would prefer to read a physical book — is it possible to subscribe for updates so I know when it comes out?

<comment><AUTHOR> I don't know if there's a way to subscribe for updates with the publisher, but if you use Twitter I'm on there as @jstanier and I give updates on how it's going. If you're not on Twitter then I can drop you an email.

<comment><USER42> I'd recommend setting up a mailing list and promoting it on your site. See the "stay in touch" section at [https://dataintensive.net/](https://dataintensive.net/) or the "sign up for newsletter" section on [https://the-cloud-book.com/](https://the-cloud- book.com/) for examples.

<comment><AUTHOR> Yeah, that's a good idea. My blog has a mailing list but I did a wonderful job of making it extremely hard to find.

</comment></comment></comment></comment><comment><USER43> Question to CTOs - are you happy? When I see what particular CTO does day to day, assuming he/she was an engineer before - it seems quite boring. It seems they've sacrificed their engineering side in exchange for a bigger salary.

<comment><USER17> The grind of constantly learning the latest technologies eventually got boring, and now I really enjoy managing developers. For me personally, helping an unhappy or under-performing developer get out of their slump is a really rewarding experience.

I don't enjoy long-winded, pointless meetings - but if you're organisation has so many of them, you'll get pulled into them anyway once you're senior enough.

<comment><USER44> i think i am an under-performing developer. if you dont mind sharing some secret sauce... what are the first questions you think about asking to diagnose whats going on?

<comment><USER17> What makes you think you're under-performing?

I think the "secret" is simply to make sure people know what they're suppoesd to be doing, that they want to do it, and that they feel they have everything they need to do it. That won't necessarily always work, because not all under- performance is work-related - if you've just had a baby, going through divorce or bereavement, I'd expect you to be 'under-performing' and wouldn't try to fix it.

If you do want a chat, I'm available on email (it's on my profile page).

<comment><USER44> thanks, will drop an email (to be clear its not like i was expecting any solutions here, i just like learning about how managers manage).

<comment><USER17> Great, I'll reply to your email. As a manager, I wouldn't discuss any problems you're having in an open forum - and I'd try to do it face-to-face as much as possible. It takes time to build up trust, figure out what's going on - perhaps you already know but don't feel comfortable, perhaps you need to work it out.

</comment></comment></comment></comment></comment></comment><comment><USER45> I'd love a blog about how to AVOID becoming a manager as an engineer or technical person. It really seems "contributors" are at the bottom of the pyramid, especially in companies whose core business is not technical in nature.

<comment><USER46> It's not particularly hard. Just never accept a leadership position :). As long as you keep your technical skills sharp, you should never be short of a job. However your income will likely plateau very early in your career. You can try to become famous as a way to counteract that, but it is substantially harder than just going into leadership.

<comment><USER45> > However your income will likely plateau very early in your career.

yes this is sad part. hoping AI will take over leadership and only AI engineers will be needed. /jk

</comment></comment></comment><comment><USER47> I can't wait for it to come out of beta and be available in my O'Reilly subscription :)

<comment><AUTHOR> I didn't even know that was a thing. :-) Ace!

</comment></comment><comment><USER48> Jstanier - Great job, this looks really cool. Curious what icon set are you using? I saw you have similar style icons across a few of your projects, is there a standard library you are using or are you creating them yourself?

<comment><AUTHOR> Hey - icon set? What do you mean by icon set? :-)

<comment><USER48> Just the images on the front page, guess a bit bigger than icons!

<comment><AUTHOR> I /think/ I know what you're talking about, but just in case this gets derailed in a back-and-forth and lost, then feel free to contact me on Twitter @jstanier or my email is in my profile - we can chat more easily there.

</comment></comment></comment></comment><comment><USER49> > If anyone's at all interested ... pitch(ing) a publisher with their own book > idea, then ... I'm more than happy to give you any advice

Really? How do I contact you?

<comment><AUTHOR> @jstanier on Twitter if that works for you.

</comment></comment><comment><USER50> Very relevant to this new team lead (since Autumn last year). I bought a copy, I can't wait to read it :)

<comment><AUTHOR> Thank you! I hope it helps. Let me know if there's anything you'd like covered.

</comment></comment><comment><USER51> A great achievement, congrats!

Although, it may never top your blog circa 2001, it's a fine achievement nonetheless.

<comment><AUTHOR> We don't talk about that blog.

</comment></comment><comment><USER52> Man you have a PhD. Is this book worth reading for someone who just have basic education?

<comment><USER53> I have a PhD. The piece of paper hangs in my bathroom so I can look at it while I shit. It was a personally fulfilling experience that taught me a lot about academic research and and is almost completely divorced from the practice of software engineering management. (and most other things.. I'd suggest never being intimidated by a PhD.) The book is written on a very approachable level, I'm enjoying it so far.

<comment><AUTHOR> Thank you, I'm pleased you think that. My PhD was in compilers anyway. I have no formal management training. :-)

</comment></comment></comment><comment><USER54> What is the format of the book? PDF? Epub? Mobi? Html?

Is it / will it be readable on a Kindle?

<comment><USER55> Pragmatic Programmers beta and published books are available as all three - PDF, epub, and mobi (which reads fine on my Kindle).

</comment></comment><comment><USER56> Great! This is exactly what I was looking for.

Will we get the updates if we buy the beta version?

<comment><USER57> Yes, the betas get updated along the way, and you'll end up with the final print version when it's done.

</comment></comment><comment><USER58> Have some questions for you. What's the best way to get in touch?

<comment><AUTHOR> @jstanier on Twitter, or my email is in my profile.

</comment></comment><comment><USER59> Embrace the dark side Luke.

</comment><comment><USER60> <3 <3 <3

</comment><comment><USER61> Clickable links for my fellow loafers:

[https://www.theengineeringmanager.com](https://www.theengineeringmanager.com)

[https://pragprog.com/book/jsengman/become-an-effective- softw...](https://pragprog.com/book/jsengman/become-an-effective-software- engineering-manager)</comment>


I think it's time we broke for lunch… (2011) - <AUTHOR> http://www.economist.com/node/18557594 <comment><USER2> No. Effect size is too large. Judges just favor a Shortest-Job-Next scheduling algorithm for ruling blocks, and short cases tend to be favorable.

[http://nautil.us/blog/impossibly-hungry- judges](http://nautil.us/blog/impossibly-hungry-judges)</comment>


Microsoft Cloud Strength Highlights Second Quarter Results - <AUTHOR> https://www.microsoft.com/investor/EarningsAndFinancials/Earnings/PressReleaseAndWebcast/FY16/Q2/default.aspx <comment><USER2> Most of Azure's revenue is inflated. It is actually fake revenue, subsidized into ELA deals. Heavily.

If you talk to customers, all they're using is AWS, and some breadcrumbs of Azure here and there.

I don't know how they're even allowed to present financials this way.

<comment><USER3> So I'm supposed to trust an anecdotal "everyone actually uses AWS" comment over an official earnings report?

<comment><USER4> I dont know about ELA deals but Azure is something like 15-20% of the size of AWS based on other various data points. My BS detector also went off about their $9b run-rate comment.

<comment><USER5> They didn't claim Azure was at $9 billion. They said "commercial cloud." They use different terms for them, whether one thinks that is meant to be intentionally confusing is another matter.

The only number they claimed on Azure, was 140% growth:

"Azure revenue grew 140% in constant currency with revenue from Azure premium services growing nearly 3x year-over-year"

</comment></comment></comment></comment><comment><USER6> I run most of my stuff on Azure. I am part of the Bizspark program which includes a generous free Azure allowance. Yes, I am grateful for that.

That said, in the past I have also used AWS and Google cloud services a lot, and I don't really have strong opinions about which features of these three services that I like best.

One thing that I do have a strong opinion on is the extremely high value of Office 365 for $99/year for the family plan. Everything works fine. We use just a bit of OneDrive storage but having all of the apps run on all of our devices is useful. On Linux, I just use the web versions.

</comment><comment><USER7> Some how these numbers are higher than AWS's numbers in the same quarter. Something weird is going on. Are they lumping other MS products which run in the Azure cloud into this figure? Office 365, etc?

<comment><USER8> The 10Q has more on this, search for the section titled "Note 18" on business segments. [http://apps.shareholder.com/sec/viewerContent.aspx?companyid...](http://apps.shareholder.com/sec/viewerContent.aspx?companyid=MSFT&docid=11131896)

</comment></comment><comment><USER9> This has to be inflated, I've heard of people trying azure but not actually using it. I've heard from two groups that tried it recently that there were pretty dreadful problems with unexplained outages or unexplained poor IO performance.

<comment><USER5> Inflated? It has been quarter after quarter after quarter. This isn't a new result.

It's very clearly not inflated. Azure is the #2 competitor to AWS at this point. Their quarterly results have been telling the tale of this build-up for the past two years.

AWS just grew by nearly 70%, and is quite a lot larger than Azure. It's not surprising that Azure would continue to grow so fast.

There seems to be a lot of confusion here about the Microsoft report. Nowhere in that report did they split out Azure sales, only "commercial cloud" ($9.4b annual run-rate) and "intelligent cloud" ($6.3b sales). The sole thing they were specific about regarding Azure, is 140% sales growth.

<comment><USER10> I think the point is that Microsoft's cloud services are rather more than Azure (even though Office 365 and Dynamics CRM share bits of Azure infrastructure such as AAD).

</comment></comment></comment><comment><USER11> Is anyone here actually using Azure? My teammates using it have encountered all types of problems, with bad stability problems (worse than rackspace and their bimonthly outages)

<comment><USER12> I do, and think it's a good proposition for startups.

Office 365 makes it easy to setup the organisational IT (login based on your own domain, email, storage, document collaboration, chat). Add Power BI if you need fancy (realtime) analytics and charts.

Then you create a private git repository (using the same login) for your startup product and configure continuous deployment using Visual Studio Online and Azure. Most of the Visual Studio Services are node-based now, so it's cross-platform and you can deploy to Linux too.

It's also easy to add other services if you want (Slack, Zoho, Google).

All this is managed with a single login, paid with only two bills (Office 365 and Azure are separate). The Azure bill can be lowered if you get into BizSpark.

This all saves a lot of work, a single person can create and manage a very advanced infrastructure without too much effort.

<comment><USER13> I think the question meant... for running applications with real workloads. IaaS</comment></comment></comment>


Find the Third Way - <AUTHOR> https://garybasin.com/find-the-third-way/ <comment><USER2> This reminds me of a quote by Emanuel Lasker (chess player)

> When you see a good move, look for a better one. —Emanuel Lasker, 27-year > world chess champion

<comment><AUTHOR> There's something there</comment></comment>


How to Save the World by Taking Back Control of Our Data (2003) - <AUTHOR> http://www.pbs.org/cringely/pulpit/2003/pulpit_20031002_000787.html

<comment><AUTHOR> PBS's Robert X. Cringely from 2003.

In particular:

"Today's news is that a cypherpunk nightmare is upon us. Information is not power after all: Old-fashioned power is power. If you aren't big industry or government, you have very little power. Once they've hacked the electronic voting system, you'll have no power at all."</comment>


Is Clojure dying, and what has Ruby got to do with it? - <AUTHOR> https://lambdaisland.com/blog/25-05-2017-simple-and-happy-is-clojure-dying-and-what-has-ruby-got-to-do-with-it <comment><USER2> It is now official. Netcraft has confirmed: Clojure is dying.

One more crippling bombshell hit the already beleaguered Clojure community when Lambda Island confirmed that Clojure market share has dropped yet again, now down to less than a fraction of 1 percent of all new code. Coming on the heels of a recent Netcraft survey which plainly states that Clojure has lost more market share, this news serves to reinforce what we've known all along. Clojure is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent comprehensive programming languages survey.

You don't need to be the Amazing Kreskin to predict Clojure's future. The hand writing is on the wall: Clojure faces a bleak future. In fact there won't be any future at all for Clojure because Clojure is dying. Things are looking very bad for Clojure As many of us are already aware, Clojure continues to lose market share. Red ink flows like a river of blood.

Due to the troubles of Lisp, abysmal sales and so on, Lisp Machines went out of business and was taken over by GigaMos Systems, who sold another troubled Lisp. Now GigaMos is also dead, its corpse turned over to yet another charnel house.

All major surveys show that Clojure has steadily declined in market share. Clojure is very sick and its long term survival prospects are very dim. If Clojure is to survive at all it will be among programming language dilettante dabblers. Clojure continues to decay. Nothing short of a miracle could save it at this point in time. For all practical purposes, Clojure is dead.

<comment><USER3> Is this an ironic homage to some piece of alarmist writing about something else? If not, it seems way over the top. It was pretty fun to read though.

<comment><USER4> I feel old now: [https://everything2.com/title/BSD+is+dying](https://everything2.com/title/BSD+is+dying)

<comment><USER5> Nice E2 reference. Hard to believe now, but back in the day there was serious debate about whether it should compete with the upstart Wikipedia. Glad they went the creative writing direction instead, there's some great stuff in there.

</comment></comment></comment></comment><comment><USER6> Clojure's not dying, but it's also not thriving[1].

I think it will continue on as a solid niche language for the foreseeable future, but it's highly unlikely that the language will grow by leaps and bounds barring some must-have innovation in the Clojure language and/or ecosystem that gets the tech world to take it more seriously.

There are so many options these days that it's tough to stand out from the crowd. Clojurescript, while interesting, is a dime-a-dozen with Elm, Purescript, Scala.js, Typescript, etc. all on offer, and with static types to boot. Also, Lisp itself is a tough sell, mainstream adoption isn't in the cards without a major paradigm shift.

[1] [https://trends.google.com/trends/explore?q=%2Fm%2F0_lcrx4,%2...](https://trends.google.com/trends/explore?q=%2Fm%2F0_lcrx4,%2Fm%2F091hdj,%2Fm%2F03yb8hb)

<comment><USER7> Lisp used to be the language for AI, could Clojure possibly steal the machine learning niche back from Python?

<comment><USER8> > Lisp used to be the language for AI

IIRC, when Lisp was a leading language for "AI", it was specifically a leading language for _expert systems_ , not ML. Even to the extent that was due to language features being well-suited to the domain, there's still no real reason to expect that suitability to translate to the radically different approaches to AI today.

<comment><USER9> > _Even to the extent that was due to language features being well-suited to > the domain, there 's still no real reason to expect that suitability to > translate to the radically different approaches to AI today._

People these days use Python for ML, which is even less suited for the domain (and lacks the ability to re-suite itself), not to mention being significantly less performant than popular Common Lisp implementation.

Our industry is strange :).

<comment><USER10> Python is well suited for ML, just not in technical sense:

it is a very simple language that's easy to use by people who have a strong academic background, but not much of programming experience (AKA: Data Scientists). Also it has a lot of numerical libraries (numpy, pandas)

<comment><USER11> ML problems are those where people benefit from the assistance of thinking more like the computer does. Python helps people think more like the computer. (corrolary: although a very similar language, Perl helps the computer think more like you do).

</comment></comment></comment></comment></comment></comment><comment><USER12> Oddly, as someone who was reasonably into Common Lisp, what really viscerally turned me off to Clojure was the use of square brackets.

This sounds petty but I actually have some rationalization for it. Once you learn to read Lisp (mostly looking at the indentation and ignoring the parens) it's really nice that there's only one kind of delimiter in the language. It allows a lot of easy structure editing with a decent editor. I had emacs set up to use the unshifted square bracket keys to create and exit balanced parenthesis pairs. Once you got used to this, this was really pleasant to write and mutate code.

As soon as I saw Clojure, I knew that my setup would unavoidably get twice as complicated because they added another delimiter that's used in random places in the code. (Why are function arguments a vector instead of a list? Just because the designer thinks it looks better? Why are let bindings a vector? Why are ordinary function calls and function bodies a list? It just feels arbitrary.) That in and of itself really turned me off. (The fact that it's the JVM really didn't help either, but that was actually secondary to the above.)

Other issues for me were the lack of two layers in the LET statement (i.e. it's (let [a 1 b 2] ...) rather than (let ((a 1) (b 2)) ...). To some that probably "looks better" but it kills the ability to use emacs's transpose- sexps to swap the order of your let bindings around.

All in all the syntax just didn't seem well thought out to me. OTOH to non- lispers it probably looked better, so maybe that was the goal.

<comment><USER13> What's interesting is that for me Clojure was my first lisp. One of the main reasons I never learned lisp before Clojure was all the parens that made the language impossible to read. Clojure cleans up the "normal" lisp syntax quite a bit, and that made it a lot more palatable.

Beauty is in the eye, and all that, but CL code still makes me want to claw my eyes out.

<comment><USER14> People complain about the parens in Lisp but what kills me about Lisp in general is not the parens but the fact your brains has to read the code from bottom to top and/or right to left. This is because of prefix notation.

And while I do not like object oriented languages its far more natural to English readers such as myself to write and read things from top to bottom and left to write.

Now of course some FP languages have operators to (Haskell, F#) to allow left to right function application and you could of course make macros in Lisp in whole it doesn't really fix the problem entirely.

You can also of course mitigate the above with judicious use of let expressions but more often than not people inline anyway.

</comment></comment></comment><comment><USER15> I think Clojurescript might be the thing. With advances in the Google Closure compiler, it's getting better and better. And the front end developer tools and libraries in Clojurescript are _the best_ out there. The holy grail for javascript exists in Clojurescript. Until then I'll keep making my Javascript env look like Clojurescript. With janky react devcards, Immutable.js, and react-redux.

<comment><USER16> I hear this a lot from the clojure community... but I think it's a missed attempt to pivot off the JVM and have clojure be useful for more people on a more popular platform.

Missed?

Yes.

Pick a thing.

Be excellent at it.

What is clojurescript excellent at?

Its a nice language, with not very nice tooling, that is hard to maintain and significantly different from the existing javascript code base you already have, with poor interop to the existing js ecosystem (it is poor, compared to some other compile to js languages).

On the JVM, java sucks, but your choices are limited; what, maybe groovy, kotlin, scale, clojure?

Clojure has pride of place as the best dynamic language in that space.

For javascript, that crowd of alternatives is _so much larger_ , clojurescript needs to _actually be good_ to stand out amongst all the others.

...and I don't think it really does.

The people who use it seem to just like it as a language; and I get that, that's a thing.

...but aesthetics are personal preference and its difficult to ague they make a compelling use case.

<comment><USER17> > with not very nice tooling

The tooling is the best. Figwheel is hot reload that never goes down, devcards is revolutionary, and a browser repl for live in editor evaluation...

> significantly different from the existing javascript code base you already > have

It actually isn't. Clojurescript is basically javascript that's immutable first, has underscore in it's core library, and then a bunch of other awesome language constructs. The libraries use the same patterns, re-frame is a nicer, more succinct abstraction over react-redux.

> poor interop to the existing js ecosystem

The interop might be the best out there. Seriously you can write javascript in clojurescript. you can straight up import es6 jsx javascript into your clojurescript code. (thanks Google Closure)

> For javascript, that crowd of alternatives is so much larger

I mean, what are the options? Clojurescript's benefits are so much more than the language. The real pluses for clojurescript are the Google Closure compiler, hot reload, browser repl, devcards, front end libraries. The language is the cherry on top. There are no alternatives that have a comparable platform not completely alien to JS developers.

<comment><USER16> > The tooling is the best.

No, it's really not.

Have you tried other ecosystems? You should. If clojure is the best tooling you've ever used, look around, there's a wide world out there.

Heck, even the article _linked above_ from lambdaisland lists tooling as one of the issues clojure suffers with.

> I mean, what are the options?

Haxe. Dart. Typescript. Elm. Scala. LivesSript. ES6. CoffeeScript. Flow. PureScript. ...

There must be what, 50 odd listed on [https://github.com/jashkenas/coffeescript/wiki/List-of- langu...](https://github.com/jashkenas/coffeescript/wiki/List-of-languages- that-compile-to-JS)

...but I mean, even if we accept that the things you say about clojurescript are true (and I don't agree that they are, but _even if_ I did), the point I'm making is that it _doesnt stand out from the crowd_ in terms of features.

Nothing you've described is something that would be missed particularly using say, typescript, webpack and npm.

</comment></comment></comment></comment><comment><USER18> > Elm, Elixir, JavaScript, seem to be better at prioritizing the humanistic > aspect. Both in the affordances of the software (Elm's famous error > messages), and in person-to-person interactions.

Can't stress that enough. I have observed Elixir community and I have to say Jose and others did an excellent job fostering a healthy, friendly and warm community. That is such an essential component. That combined with standing on a solid, reliable, battle proven platform (Erlang's BEAM VM) makes for a powerful combination. You see them interact and learn, and ask for help and you think as a new comer "Right on, I want to hang out with these people". Then you run some benchmarks, check out some docs, tutorial and think "Yeah I made the right choice".

So my recommendation if you want to build programming language community - copy what Elixir did and it will be a good start. That means both community, outreach, documentation as well a technical foundation.

<comment><USER19> I tried Clojure and literally within the first hour got a super ugly Java stack trace from trying to add two numbers, and that was after already being a bit miffed by JVM startup time (i'm very big on instant unit test feedback). Meh.

<comment><USER20> If you attempt to use edit/compile/restart method of development that most languages use, in the words of south park, "You're gonna have a bad time".

Clojure doesn't make it nearly clear enough that development needs to be performed interactively against a running instance of your application, with a REPL integrated into your editor. And yes tests run instantly when doing this.

Anything else is pure pain.

</comment></comment></comment><comment><USER21> clojure's killer app, datomic, is closed source

in my opinion, this is a key reason, why clojure is not thriving

i can't think of any (problem) domain, where clojure have a framework or library, than is significantly better than most other frameworks or libraries

if you are not number 1 at anything, it is hard to thrive

<comment><USER22> I use Datomic everyday. While it's certainly a stunning piece of technology and you could pry it from my cold dead hands, I don't think it has _that_ much bearing on the growth of the Clojure community.

<comment><USER23> Sure, but that's the point: _if_ Datomic is "the best thing Clojure's got" as far as killer-apps go—and it's not really that important to the community—then Clojure doesn't really have a killer app.

A killer app is something that looks like Rails does in Ruby, or Phoenix does in Elixir: a thing where 50%-or-more of the people learning the language are only learning it in the context of using that one framework, and so often get confused as to what's a feature of the language vs. a feature of the framework.

Which is, y'know, an awful annoyance for the people who use the language for other things—but boy does it pull people in.

<comment><USER24> Clojure, and lisp in general, tends to avoid the "framework" way of thinking prevalent among object-oriented languages. It's therefore no surprise that something like Rails hasn't taken off.

There are, however, libraries and patterns which are very common, ring for example.

<comment><USER23> I'm not sure that Clojure avoids it, per se; a framework isn't something you set out to build by saying "this shall be a framework." A framework is just a library, exposed directly as functions and data in a given runtime, that has enough internal structural complexity and "active" logic that the framework offers high-level abstractions that pre-compose its components into functional arrangements, rather than expecting you to DSL-glue them together yourself.

Consider: OpenGL/DirectX are essentially "frameworks." They rely on you to specify the high-level (scenes) by calling the library APIs; the library does the medium-scale logic of managing the GPU; and then the library calls back to your code (shaders) to get the low-level details of textures and vertices specified to it. That's a framework! And there's really no way that it could be anything _other_ than a framework.

If Clojure doesn't have any "frameworks", that's not because Clojure does something to avoid making libraries into frameworks; it's more because nobody has built a library that inherently _is_ a framework, specifically for Clojure.

</comment></comment></comment></comment></comment><comment><USER25> "What is right is not always popular and what is popular is not always right." -- Albert Einstein

I love Clojure, am more productive in it than any other language (and I've done a lot in my time, including the other FP languages mentioned in this thread) but I have to concede that most people will just not like it or get it. And that's fine by me.

I also like alternative music. Most people will never like it. Most people like mainstream pop. This is also fine by me.

Oh and I certainly would never go back to a mutable-by-default language like Ruby. I mean if it works for you, do it. But I think you are crazy.

<comment><USER26> I heard somewhere that over half of developers are new to the field.

What disheartens me is that the majority of developers care very little about programming. They care about things going out the door fast, quality be damned!

I never thought of Clojure as a language that would catch on to the 90% of shops out there. That's what ruby and python are for (and of course Java, but that's for historical marketing reasons.)

What I have thought the niche of Clojure and other languages like it are larger scale projects and established places that care about robustness and correctness. Where the wishy washy ways of the pythons and rubies of the world can can a real issue when not done correctly.

</comment></comment><comment><USER27> I really hope it isn't dying since it's by far the most pleasant language I've ever worked in. Now that I've spent enough time on it I'd very much like to use it for the rest of my career. I suppose if it does die out there are other Lisps available despite the claim that Lisp is dead.

</comment><comment><USER28> Why would you expected a dialect of Lisp to become popular in the Packer's and Pointy Haired Bosses Paradise (a ready-made ecosystem for sweatshops and coding factories of easily replaceable coding drones)?

A bit more seriously (which does not mean than anything in the previous paragraph is less true) the Java ecosystem has been grossly oversold from the very beginning, and even Rich himself has been converted (I still remember how I spat when I listened to his praise for Java as the best target platform in his very first marketing videos).

Clojure has been very well positioned and cleverly promoted (basically bringing decades of research by very bright people culminating in the Common Lisp to the Java Land of packers) but there was (and is) no demand for it and very few of those who could understand and appreciate the principles and ideas on which it has been founded.

It is dying for the very same reasons that the Common Lisp is still dying - The Worse Is Better or _Idiots, Idiots Everywhere_.

No one really needs a perfection (approaching perfection) of the great languages. The popular crap to get shit done for a paycheck (Java, Javascript, Ruby you name it) is what is in demand.

But this is rather a common pattern. This is exactly how the Upanishadic philosophy has been degraded into cryptic meaningless tantras, how Buddhism has been transformed into debased Lamaism, how western philosophy ended up with Hegelian nonsense and Marxism or what a sophisticated noise we have instead of Bach. The very same pattern. The world is dominated by idiots and will always be.

<comment><USER29> "even Rich himself has been converted"

I'd love to know where you learned this, or why you believe this. I'd be very interested to hear what he had to say about the change of heart.

</comment></comment><comment><USER30> Going further, it seems like the whole category of alternative languages hit a peak about three years ago, and interest has been dwindling since. It's like coders got their fix of "new ways of thinking about code", and now have gone back to whatever they feel most productive in.

Moreover, the buzziest alt languages now (Elixir, Go, Kotlin) seem to be much closer to existing mainstream languages than the buzzy ones of a couple years ago.

<comment><USER31> Ultimately, the value of a piece of code is decided by the functionality it offers, rather than what language it is written. Thus, project with 'I made X using Y' formula, while it might be a cool personal achievement, doesn't make it go beyond the confinement of its intrinsic functionality. A web server written in clojure, doesn't make it a space rocket, and certainly not making you a rocket scientist.

<comment><USER32> Alternatively a programming language shapes your way of thinking about a problem which can in turn affect the quality of the end product. If immutable data structures and a functional approach produce easier to test, less buggy code it can be argued those language features contribute to making the world a safer place.

</comment></comment></comment><comment><USER33> >> Someone asked if their were any Clojure failure stories.

Yes, unfortunately there are a few that I'm aware of. I don't want to go into detail, but I've definitely gotten more SOS calls than I care to count. I'm okay cleaning up messes, but Clojure allows developers to really hang themselves in ways that they can't in other languages simply because you _can 't_ do those things in other languages.

Clojure isn't an easy language to get, or rather, it is easy to reach for very complex, totally passing up the very simple tools the language gives you. The language is very simple, and I think that throws a lot of people, especially if they come from languages with more boilerplate baked in.

Personally, I love Clojure, but I never considered it practical for any team that is larger than a handful of developers, and it is certainly not safe for every developer to use. I'm using it on my current project because I'm working alone, and in keeping it small and focused, I have no plan to change that.

Is Clojure dying? I don't really know. I've never met enough Clojure developers that stuck with it long enough to move the meter to "massive uptick," so there isn't much of a down-slope relative to "alive." I've always seen it as a niche language with a wonderful community. I sometimes joke that I know all 50 people in the US who actually know how to use the language.

</comment><comment><USER34> I really hope this isn't true, Clojure is my favorite programming language. I feel that it spoiled me. Builds are easy, code is elegant and easy to parse, functional programming combined with immutable data structures is beautiful. It also is great for "full-stack" devs in that there is little context switching between server and client.

I think the "killer app" that Clojure needs is that it should be compilable into C/C++ with the same great interop it has with Java. It would be amazing to be able to utilize all those libraries, all those frameworks, all that code... in a Clojure REPL!

<comment><USER34> Yes, I know there is Chicken Scheme and Guile. I prefer Clojure over them though.

<comment><USER32> For the niche that Python enjoys (data science, devops, machine learning) there's also Hy (hylang.org) which has more or less the same syntax as Clojure. With Clojurescript, Hy and Clojure you can use Clojure syntax in all 3 major layers: front-end, scripting and compiled/back-end.

<comment><USER34> Haven't seen Hy yet, thanks for pointing it out! I have been getting back into machine learning recently and Python dominates. Great to see a Python lisp!

</comment></comment></comment></comment><comment><USER35> Clojure's "killer feature" for me is the by-default persistent data structures.

Are there any other functional languages out there with similar features? Lisp or otherwise.

<comment><USER36> Erlang/Elixir also is immutable & persistent by default.

<comment><USER25> It is immutable and persistent, but not with the same performance characteristics. It lacks Bagwell's data structures that allow structural sharing. Take a 10 million item list in elixir and 'change' (return a new) the 5 millionth element. Time how long it takes. Do the same with clojure. Compare.

<comment><USER37> That was true a few years ago, but not anymore: [https://medium.com/@jlouis666/breaking-erlang- maps-1-31952b8...](https://medium.com/@jlouis666/breaking-erlang- maps-1-31952b8729e6)

(You would have to use a map though, the native lists are still plain old lists)

</comment></comment></comment></comment><comment><USER34> One of the best things about ClojureScript is the build process using lein. I've had a very stable build for years now, whereas JS has had grunt, growl, webpack, etc.

<comment><USER17> Yup, front end development is light years ahead of JS. sad

<comment><USER32> Exactly. Wave goodbye to Webpack, Babel, Redux, Gulp, Grunt, Browserify, Brunch, Yeoman and the rest of the usual suspects. I'm baffled as to why Clojurescript + Leiningen isn't the preferred way. Javascript Stockholm syndrome perhaps?

<comment><USER25> It's true of everything in life. The best is never the most popular. The most popular is often, frankly, crap. Why would programming be any different?

</comment></comment></comment></comment><comment><USER38> I do wonder how much the purchase of Sun (Java) by Oracle and/or the slow down in Java advancement has affected those languages that a primarily hosted on the JVM.

<comment><USER39> I always thought the Java tie-in was a double-edged sword. For some potential Clojure users, in addition to learning the language they were interested in, they'd also have to half-learn a language (and its tooling) that they probably weren't interested in.

I guess in the US there is/was an assumption that everyone coming out of the computing education system is already experienced with Java.

<comment><USER40> I can't find the quote for the of me, but it was from Rich Hickey and went something like: "First, you use Clojure to escape Java. Then, you use Clojure to write better Java."

I definitely found it to be true. Clojure takes the good parts of Java's OO system.

<comment><USER32> Doesn't make any sense as Rich makes a big point of having wasted years writing large applications in Java and C++ before discovering Lisp and FP. If anything Clojure is the ultimate anti-OOP which, I think, partly explains its lack of adoption sitting, as it does, on top of a mass of libraries designed with OOP.

<comment><USER40> ok, found it: [https://stuartsierra.com/2008/08/08/clojure-for-the- semantic...](https://stuartsierra.com/2008/08/08/clojure-for-the-semantic-web)

I think it was in reference to the java ecosystem, more than "a better way to write java," although I still see it that way.

<comment><USER32> How can Clojure be reduced to "a better way to write Java" when you can live quite happily in Clojureland without writing a line of Java or importing a Java library?

</comment></comment></comment></comment></comment></comment><comment><USER41> I had never touched Clojure until a few weeks ago. I started learning it because Spec got me really excited and I want it or something a lot like it right now.

</comment><comment><USER42> So, a keynote on conference about a dying language has mentioned that another, unrelated language is dying. And people are taking notice.

It does not make sense.

</comment><comment><USER43> Within the monthly HN "who is hiring" posts, Clojure and Ruby appear mostly flat[1], albeit with Ruby at a much higher level.

[1] [http://www.ryan-williams.net/hacker-news-hiring- trends/2017/...](http://www.ryan-williams.net/hacker-news-hiring- trends/2017/may.html?compare1=Clojure&compare2=ruby)

</comment><comment><USER44> I spent the better part of 2013 - 2015 learning and working with Clojure. I love the language and the feeling I got solving little problems like Project Euler or 4clojure. However, I could never quite transition to feeling productive making larger projects and found myself using reverting to Scala or JS instead.

</comment><comment><USER14> I'm try to understand how Ruby has any relation to Clojure's purported dying other than I guess a few critical things were said at a Ruby conference.

What is becoming less popular is dynamically typed languages or perhaps more correct to say languages who's types are not statically analyzed at compile time.

So if there is anything hurting Clojure I believe it is the increased uptake of languages with much better type systems than in the past (Scala, Swift, Rust, and even Go).

Particularly Go as clearly it is eating a lot of the jaded JVM crowd (that .NET core should be taking up but for various reasons have not).

Hell even Python is moving towards being more type oriented or at least having support for optional typing.

That being said I think out of all the dynamic languages Lisp, and thus Clojure are the best. I even like Elisp. Its the only time I do like a dynamic language (other than quick shell like scripts) and that is because the runtime is integrated so heavily with the development that essentially you are getting your types constantly checked (as well as auto completion and code lookup).

</comment><comment><USER45> Front page rank #22 (after 18hs) with 208 points and 192 comments on HN on a dying language.

Shouldn't _< put dying thing here>_ be met with a lack of interest?

<comment><USER46> Some funerals are attended by a large number of people.

<comment><USER45> Haha, so people are here to say goodbye to clojure? :)

I think that only works for concrete things, so in OO that would read: objects can die, classes can't.

</comment></comment></comment><comment><USER47> This was a really well written article. Nice to see the nod to Larry Wall's excellent talk on postmodern languages.

<comment><USER32> A lot of people who have never used the language sneer at Perl but I worked with it almost exclusively for the first 10 years of my programming career and still have a deep appreciation for the elegance of its design and the great mind that gave birth to it. Perl is the original linguist's programming language, superseded by Ruby, some would argue, which in turn was superseded by Perl6 with its built-in grammars.

<comment><USER47> Yea...really wish Perl6 was more polished now.

</comment></comment></comment><comment><USER48> I think Clojure's mistake is to sell itself as a JVM language. Sure, there are lots of people who love or need to use the JVM, but for everyone else it is a downside. There is already one language that is the queen of JVM, Java. Every other language is faded to become a second class citizen.

</comment><comment><USER49> There is something missing in the "simple vs. easy" argument. You need to put things in the perspective of evolution.

Designing an "easy" language is easy because you can usually resort to human intuitions, yours or somebody's else. Everyone can tell your language is easy or not; although there is no single criteria of what is easy, it's still possible to come up with something that many people agree are easy.

Evolving easy languages is also not hard. Just follow the trend and keep making it easy to do whatever just became popular. Statistics, backend development, machine learning, whatever. If some early design choice turns out to be a bad move, just provide alternatives. People don't have very high expectations about the internal coherency of your langauge, so you have much freedom in evolving your language.

Designing a "simple" language is much harder because it requires a very deep understanding of the underlying structure of your runtime environment, the kinds of systems you want to build with the language, and the structure of computer programs in general. Appreciating easiness requires experience and insights, and simple things can appear complex when looking from a different perspective.

Even if you are super smart and came up with a amazingly simple language, that's only the beginning. Sooner or later, whether it's new area of programming or a design mistake surfacing, you need to evolve your language. And that is hard, because blindly adding features will destroy the simpleness and your language degenerates into an "easy" one. Instead, you need to carefully think about the natures of the new requirements, challenge the assumptions underneath the original design, and restructure your design. This process is often slow and can be more challenging than the original design process.

Of course as the article says, "simple" and "easy" is hardly a dichotomy; what I described are extreme cases, and most if not all languages fall somewhere in between and exhibit properties from both sides. But I think it's helpful to think the two dimensions in this way.

</comment><comment><USER50> I have to say, it's been long since I searched for Hickey or clojure conf talks. Maybe that's just me and there are lots of new valuable stuff, but in a way it's hard to top cljs, core.logic, datalog in terms of brain wow.

</comment><comment><USER51> I quit using clojure because (i) no C/C++ FFI, (ii) lack of strong type system, and (iii) horrific startup times (although clojure itself is fast, its startup time is not fast).

</comment><comment><USER52> Once modern languages like Crystal, Elixir and probably all the rest begin to allow AST manipulation, the appeal from Lisp dialects diminishes even further as like when mainstream languages began to ship with a garbage collector. Clojure like all Lisp is not dead or dying, it's not just for everyone, and that's fine.

</comment><comment><USER53> I wonder if a microservice library or framework could become the killer feature to break clojure out of its niche. It could still be used by other jvm languages, possibly js languages, and wouldn't require betting the farm on it to try it out.

</comment><comment><USER54> Clojure is a tool for people who know their doing by people who know their doing.

Just like a fine Stradivarius violin. For me the violin would be indistinguishable from an entry level violin but for the master it's a very powerful tool.

<comment><USER55> That analogy can be used both ways!

"I'm an artist, and if you give me a tuba, I'll bring you something out of it" - John Lennon.

</comment></comment><comment><USER56> This is odd. I find myself moving to Assembly nowadays.

<comment><USER57> There will always be room in the market for trendy, abstracted languages like Assembly that provide simple syntax and garbage collection to sort memory management. Sometimes I think it's too user friendly though:

        assembly new project

When you scaffold an app like this in assembly you hardly know what it's doing under the hood.

<comment><USER58> I thought programminggeek was making a joke. There's a high level language called Assembly? If so, it's 100% unsearchable. Or are you joking too? Got any links?

<comment><USER57> I think they were serious. I was certainly joking.

</comment></comment></comment></comment><comment><USER59> These decline and declare articles are programmers equivalent of alien- abduction tales in dive bars. I was - sniff- abducted by a foreign framework - sniff- they made me do this - sniff- they made me learn - sniff - put there knowledge everywhere in my brain. It was horrible. \- sob -

It sounds horrific but you are not bound by oath and vow to the framework you love. You must not jump ship, you can ride two or three, depending on where your money comes from.

</comment><comment><USER60> For me, there are a number of ideas in Clojure that I think are wonderful. I just really hate reading and writing lisp code. I can't think of a syntax I like less, unfortunately, even including junk like Visual Basic.

</comment><comment><USER61> Ultimately a thoughtful read.

</comment><comment><USER62> Certainly not this, but it's a great tune anyway: [https://www.youtube.com/watch?v=8PLE3IjTRb8](https://www.youtube.com/watch?v=8PLE3IjTRb8) \- The Wurzels, Ruby

<comment><USER62> ^ <step here> ^

</comment></comment><comment><USER63> Is Ruby supposed to be an example of "not dying" language? Because it has certainly passed its glory days as well.

Also Common Lisp is better in every way ;) There's even a JVM implementation (ABCL) for people who like that sort of stuff.

<comment><USER22> I don't know but it seems to me Ruby is dying the same way anything else with 200,000+ questions on Stack Overflow is dying (i.e. it isn't).

<comment><USER64> David, you have to put more bugs in ClojureScript - we need way more questions on StackOverflow ASAP! :)

</comment></comment></comment><comment><USER65> I'm still left with the question of "why all the parenthesis?"

While it might sound silly and reductionist, it is ostensibly the single hurdle I could never overcome when it came to lisp languages. The majority resides with the fact that it could work without them, so I see it as an ancient artifact.

<comment><USER66> There seems to be a very nice solution to the parenthesis problem: [https://sourceforge.net/p/readable/wiki/Home/](https://sourceforge.net/p/readable/wiki/Home/)

I have no idea why it hasn't caught on. As far as I'm aware, there's no Clojure implementation. Lispers like their parentheses.

<comment><USER67> (we) lispers LOVE our parentheses.

"Elegant weapons... for a more civilized age."

Ref: [https://xkcd.com/297/](https://xkcd.com/297/)

<comment><USER68> I love that particular xkcd

I'm not even a lisper.</comment></comment></comment></comment>


Microsoft:'no known ransomware' runs on Windows 10 S – so we tried to hack it - <AUTHOR> http://www.zdnet.com/article/microsoft-no-known-ransomware-windows-we-tried-to-hack-it/ <comment><USER2> > But one common attack point exists. Hickey was able to exploit how Microsoft > Word, available to download from the Windows app store, handles and > processes macros.

Of course that's how they did it.

<comment><USER3> No doubt. I get that MS doesn't want to break the sometimes decades old solutions people came up with for around the office by removing VBA but they should offer a version of MSO that simply does not support it.

Consumers and younger businesses with no VBA dependencies could buy it and companies that need to can continue to buy a version that supports VBA.

The only draw back I can think of is the confusion this could cause when buying. Maybe they could just rip VBA out of Office all together and sell it as an add-on to those who need it.

<comment><USER4> A somewhat good idea, but you can disable macros through domain group policy.

[https://superuser.com/questions/1073060/disable-all- microsof...](https://superuser.com/questions/1073060/disable-all-microsoft- office-macros-globally-for-all-users#answer-1073064)

</comment></comment></comment><comment><USER5> I think few hackers are going to write code to hack the five or six Windows 10 S users...

<comment><USER6> You make a good point. Although the purported motives for Windows 10 S are somewhat agreeable, like approved apps to stop users downloading malware, the whole concept needs to die in a dumpster fire.

You just _know_ that it'll start with not allowing obvious l33t hacker apps onto the store, and swifty end with any app that features a hex color vaguely similar to Pepe the Frog's to be banned because some wannabe buzzfeed writer said that that shade of green is a hate crime (hugely exaggerating here).

</comment></comment><comment><USER7> There is no try; only hacked and soon to be hacked.</comment>


How to make the most of your Website Feedback Tool - <AUTHOR> https://www.bugmuncher.com/blog/make-the-most-of-your-website-feedback-tool/#.Wt9TrXP5mbE.hackernews <comment><USER2> >Errors are opportunities

I love this. I've found that my most engaged users are the ones that report errors, churn less, etc.</comment>


Ask HN: Nowhere to go from here? - <AUTHOR> I'm feeling a bit discouraged and hopeless in regards to "where to go/what to do next".
I'm 23 with no degree, and I work in web development as a senior team lead for $130k/yr salary in Utah (silicon slopes area).
I've been at this job for over a year and the "hard" programming problems feel already solved.  I spent the first little while creating a solid framework for creating new web solutions, and at this point, my job is starting to just feel like data entry. It's a lot of "make a page that does this", or "create a system that allows us to do X", and I'm just filling in the pieces and naming the fields, etc.
There are interesting problems that I want to solve regarding AI, writing compilers, creating programming languages, etc, but it seems like no one wants to pay me to work on those problems.  I end up just spend most of my free time doing that and dreading returning to work.
I also feel like I can't advance or change positions because according to everywhere that I interview, I'm already at a real high point in salary and I constantly get low balled for offers.
I just feel a bit stuck and would appreciate any advice.
Thanks <comment><USER2> Don't sneeze at the $130K in Utah. This may be the best financial circumstances you ever have in your life. Make the most of it. If you've got debt, pay it off. Bank a bunch of it, as nostrademons said. If you feel like it and they'll agree, take a sabbatical and do whatever you feel like (AI research, travel, ski for the winter, whatever). It'll never be this easy again.

(And yes, it seems to me that you are massively overpaid for the local market. In fact, if you don't mind sharing, who's paying you that kind of money here?)

But you feel like you're dying inside, because the job is too easy. One way to deal with that is to go to your boss and say "Have you got anything harder for me to work on?" Or look around and see what else needs solved in software where you are, and tackle it. (If you're getting your "real" \- official - work done, you don't even need to ask for permission.)

Another approach would be to go part-time (if they'll let you) and go to school. If they pro-rate the salary, you'll be fine for money. You don't really need to go to school for the degree; what you need are people that you can work on hard problems with.

</comment><comment><USER3> Save some money and then either strike out on your own or take a pay cut to break into an area that you really want to work in. The whole point of being overpaid is to have some money to buffer yourself against either unforeseen bad luck or local maxima that you can't get out of without investing time & money into.

</comment><comment><USER4> I'm quite similar to you, problems are what motivate me and I also don't have a degree.

First thing I would do in your position is to get a degree. In my case it's for immigration. I just need that piece of paper so I'm looking at more practical universities, not necessarily prestigious. I'm looking at WGU[1] because they geared around professionals who might already know course content. Regardless, put that $130k to good use.

What I do in my spare time is contribute to open source projects. If I can't find one that piques my interest, I start one (and subsequently they get no attention, but that's not the point). I work to get paid. Right now I'm lucky enough to be working on some interesting graph theory problems, but it hasn't always been that way and nor will it necessarily stay that way forever. If programming is your hobby, maintain that hobby. Your employer has other things to worry about.

 _> [2]: Even if your job was tasting pies, every now and then you'd taste a bad one._

[1]: [http://www.wgu.edu/](http://www.wgu.edu/) [2]: [https://www.reddit.com/r/Showerthoughts/comments/4toouj/some...](https://www.reddit.com/r/Showerthoughts/comments/4toouj/somewhere_in_the_world_there_is_somebody_with/d5j58rf)

</comment><comment><USER5> I am in a similar position (22 years old). I have been "coping" by working on machine learning projects on the side in the area that I have determined gives me a lot of meaning (teaching AIs to learn correlations between diet and autoimmune diseases). I do this and trial it with my friends who have AI issues, and work normally during the day putting all the discipline I can into just focusing and doing good work for the 9-5 I am expected to. Hopefully, eventually, I can spin off my work project and/or one of my side projects will get traction. I should have enough capital to live off my investments/retire and work on harder, more interesting/long term problems for the rest of my life in about five years. Put in those terms, it is not as hard to keep grinding.</comment>


Show HN: UX-App – Interaction and User Experience Design App - ux-app https://www.ux-app.com/

<comment> ux-app Hi, This has been my side project for a while now. I've posted lots of updates recently and would love to know what you think.

Cheers, Eli</comment>


Ask HN: Where to find a good UI designer? - <AUTHOR>

I've tried finding people on Craigslist but the quality of the candidates is not up to par with what we need. How did you guys find your UI designers? Any particularly good sites that you have used? <comment><USER2> <http://themeforest.net/> \- <http://DeviantArt.com> \- I usually contact the Designer straight if I like their Portfolio

</comment><comment><USER3> If you see a site that you really like the UI of, don't be shy to email the site operator and ask them who they used.

</comment><comment><USER4> Have a compelling story and show that you want to embrace UI as a core strategy driver</comment>