Ask HN: Hiring managers, what tech skills will you be hiring for in 2017?
Please be as specific as possible. Also please mention your company and/or industry.
This should help folks trying to get into your company/industry on what they need to know and conversely help you in finding a better pool of candidates.
241 comments
[ 2.9 ms ] story [ 97.4 ms ] threadAlso backend and data engineering roles (C++/Java/Go/Kafka/etc) are in high demand here.
SoundHound is hiring in SF/Santa Clara/Toronto.
Sidetone: I am semi-actively looking for a Javascript Engineer job (fullStack or frontend with ~2 yr exp). Are y'all hiring?
Can you explain what is your product? Not 100% sure I understand.
I think they relied on user submissions for that functionality, but if it works it works.
I've since switched to a personal policy of "no Google stuff on my phone", which means not having access to the Play Store. I haven't checked lately to see if SoundHound is on Amazon's app store (it wasn't when I first checked, but neither were Spotify or TuneIn and now they're both available, so I might go do that).
What do you look for in a resume or application that would make you confident that you've found somebody with that experience?
Our stack is node.js/React/Postgres so knowing any/all of those is a bonus, but we don't specifically target those skills – we instead look for a diverse, intelligent set of engineers who have a strong technical background or a newer technical background but heavy experience in a non-programming field (mathematics, economics, architecture, teaching, customer support, etc; they all have their benefits). Interest in being "full stack", participating heavily in the product management process (strong opinions loosely held!), and a belief in the critical importance of design & UX (unfortunately still heavily undervalued in the Enterprise space...) are important.
Hiring in San Francisco & Washington, DC by the way.
troy.goode@lanetix.com
But it is really sad that people mostly hunt for keywords in resume.
• ability to assess tech/architecture risks in apps
• experience in devops automation ("secdevops" if you will)
• proven skill in communication regardless of depth
The ideal candidate would have all three, but I could settle with any two of these and still be happy.
I am not currently hiring, but I'll gladly keep any CVs I receive and prioritize follow-ups with anyone who reaches out to me directly. Austin/DC for curious souls.
---
p.s. the web appsec space is in ludicrous demand. If you've got a breaker mindset, you'll probably come out ahead if you read up on it. If you're a developer right now and want to dip into it, I'd suggest: https://www.amazon.com/Web-Application-Hackers-Handbook-Expl...
Trust me, us security folk will thank you. Heck I'd suggest it to non-hackery devs too. It's a good way to find out how us security types see the world.
What if I am infosec/netsec/whatever student and I watch a ton of Pluralsight on AWS and Docker and I am starting to build my own lab. Will people hire someone like me? I ask publicly because I assume I'm not the only one.
About that... you know what's more likely to get you hired in the space? If you have no work experience in appsec but walk in and tell or show me a pattern for how you automated appsec testing in a build pipeline or QA process at home and describe the challenges you had to overcome, or if you have a few fleshed-out bug bounty submissions (with exploits) and can describe your favorite one in depth, or if you've taught yourself how to review code for flaws and could do it in front of me in an interview setting, I might be quite willing to waive the years in appsec requirement. Other smart hiring managers probably will too.
https://www.owasp.org/index.php/Category:OWASP_WebGoat_Proje... <<This is a good starting point for learning how to break things. Also for learning how to fix them :)
If you already have that experience but not specifically in security, it'd be a great fit and you'd be encouraged to apply wherever automation is even barely touched on as a requirement.
Guarantee you any appsec hiring manager will consider that background.
I'm a senior developer and I made a name for myself when we started having the requirement. I helped secure ~10 webapps as I was the most knowledgeable about security amongst the devs.
The app sec guys I know at my company, though intelligent, are not strong developers. There were times I spun a story to get them to mark something as false positive - or I knew what the scan flagged for and coded around it. I know, bad practice, but sometimes the scanners mark something as critical when IMHO it's not.
Once our apps were secure, maintenance is pretty low as we'd just fix any new vulnerabilities introduced by coding, or updated by the scanner tools.
Do you see a need for strong developers in app sec world? If so, any recommendations on ways to make the leap? Not really looking for something where I just click a button and scan...but something more in depth that would use my development experience. I have a Security+ cert, doubt I can get a CISSP since I don't know anyone with it to get sponsored.
As for strong developers in the appsec world, certainly. Especially if you have a strength in the automation side, you can easily carve a niche out for yourself. The main two areas where I can see a dev taking charge are in driving the use of security features in frameworks product teams already use (this is a HUGE bullet being pushed by notables in AppSec as it reduces the effort involved in uptake of secure coding practices) as well as in leading automation of new tooling in support of new frameworks. There's also the angle of developing custom solutions to address firm-specific problems, something appsec people without a strict development background will have a hard time doing.
Quite a few appsec leads prefer bringing in developers with a breaker mindset in as appsec hires, so yes, there's always room. Depending on how you answer the question "what does 'secure ~10 webapps' mean?", you can probably easily score a lateral move into AppSec (Senior Dev -> Senior Security Engineer or Senior AppSec Consultant/Engineer).
My keybase profile has all my contact info if you want more tailored guidance. Even if you don't join my firm or any of the other firms I have a hand in shepherding, we desperately need more people in appsec, so I'm all about sharing this knowledge.
I'm a tech lead who's always been interested in appsec(very passively), but it always seemed like a long journey from here to there. And I was under the impression the rates were pretty similar which made the task seem more daunting.
I can share more detail in private eg on twitter.
+ for new web platform things like Service Workers, advanced SVG.
Could care less about whatever franework is hot this week.
This might explain why companies want H1Bs so much. Places like India and others tend to produce very pliable candidates who will just take orders and execute. I think this is a much bigger factor than wages.
Yikes. Can't help but think that you really just want a robot.
I look to hire people who just need a job. People who are qualified, but not overly qualified. People I know will depend on the job for a long time, but not looking to make it their lives. Hard workers - getting there on time, but also leaving at the stroke of 5. Ivy league schools are a red flag. Huge resumes are a red flag. These people will constantly question whether every decision is optimal, prod incessantly at company strategy, continuously try to impress, and are always hungry for praise, recognition, and "interesting work." When they get bored after 6 months, they quit and go somewhere else (remember they can easily do so because of their pedigrees), often to a competitor, bringing company secrets with them.
I need someone loyal, who knows how to take orders without question, and is prepared to do the work that needs to be done day in and day out because they want the paycheck. Reading the above, you might think I'm a terribly demanding boss, but using this hiring strategy has produced a 100% employee retention rate and by all accounts we are all quite happy.
"a reliable person who can actually, really, like, totally for real drive a problem to resolution and then go spend time with family. if there's an emergency, they pick up their phone and try to help."
this is a small percentage of the population, but big enough. it's why we (based in california) have a 75% remote workforce. hint: we still pay california $. that's how you retain talent. everyone on my team lives in huge houses and i live in an apartment.
you'd (well maybe not you, but you know what i mean) be surprised at the number of super-intelligent ("smart") people who can't solve problems when the pressure is on.
My job entails emergencies from time to time, and it's rewarding to solve an issue at the customer, before it gets out of hand, while still solving problem on the long-term roadmap during the day.
What I do regret is the complete lack of remote, meaning I will pretty much leave this job soon, as my fiancée is currently living on the other side of the planet.
It's great to see companies that do care for employees well-being in other ways than office perks, and I'd love to see more of that in the future. Are you still looking for applicants?
i don't recruit on hn. i will say this though: most people like you, if given the opportunity to work for a smaller, unknown firm for less money remotely, and a larger well known 'famous' firm for more money on-site, they will usually choose the latter even if they really want to work remotely.
in other words, "i want to work remotely" usually really means, "i wish i had all the upsides of BigCo with none of the downsides."
I can't blame you on that one.
Still, I want to address something. Remote work is a different paradigm, it doesn't make a lot of sense to compare the two of them. The upsides are pretty different, and so are the downsides.
I'm sure some people do not realise it requires a wildly different skill set, as well as a different mindset, to work remotely. The first thing that comes to mind is communication, the next is processes, and that's not the end of the list.
I'd take the job getting me closer to my loved ones any day over a job at BigCo personally, especially considering I feel strongly about the upsides. To each his own, I guess.
Are you willing to share any communities or other resources you do use for recruiting? No pressure at all here, just curious.
(Not always successfully -- I have to admit -- but I try).
I've seen a couple of such shitstorms where we had to hack on production systems to get them back to work quickly before thoroughly fixing the actual problem. Almost always, it could have been prevented with proper unit testing, code reviewing and more thought-out deployment processes.
1) Anything that can be effectively described as "blue collar" will probably be replaced by automation within 3-10 years depending on the job. 2) Creative thinkers should be valued more highly in the tech field than those that can just follow orders blindly. Very few tech fields emulate an assembly line and the ability to think for yourself and develop an alternative solution is and should be highly valued. 3) Most people in the tech field, both employees and employers, are probably intellectual to a degree and free thinkers in and of themselves. So the cycle continues.
I'd also like to point out that this idea of a blue collar work ethic is somewhat flawed. There is not specific work ethic associated with the blue collar worker naturally; it's just a result of never having enough money for pleasure, so work becomes a part of the routine. The job doesn't matter as much when you're dirt poor as long as it's making money, and the risk of job loss is what you're describing as loyalty. This is really nothing more than a capitalist machine at its worst, not some utopic worker's attitude we should all aspire to.
A lot of management hates this. Less skilled managers, just want a dev shop where they can build and assemble parts.
I wouldn't work for this guy, I want to work with people who are smarter than me and from whom I can learn new things. That said, he's right to not want someone like me, I get bored pretty quickly when I'm the smartest guy in the room so I try like hell to avoid that situation. But to each their own of course.
How would is such a person define success for themselves, and how does your prescribed plan achieve that?
In other words, are you prescribing a plan that is beneficial for the company, but bad long-term for the employee, because they didn't grow enough by not 'devoting their life to their job'?
I get this.
100% owner also means they bootstrapped and were a solo founder.
By the way 7 figures covers everything from 1,000,000 to 9,000,000 - so I read it as being barely seven figures in profit, or I would accept if the actual bottom line profit were 700k-1M (so that it's a bit of an exaggeration to call it all "profit"). However the top line (sales) has to be (well) over 1m or I am unhappy/consider it too much embellishment.
OP - what does the top line look like? Roughly how many employees do you have?
The best advice to take from your post is to make sure you know which type of company you're applying to. A small bootstrapped lifestyle business probably won't hire like a hot SV funded startup, which makes a lot of sense.
I thought you had 100% retention rate?
Those who left were hired at an earlier time when I thought hiring the top tier Ivy Leaguers was the way to go.
I understand your reasoning when it comes to well defined business requirements with well defined technical problems. But once the initial set of requirements are done, how do you proceed? I suspect you need at least some amount of overachievers to fill mid-level management roles.
Technical managers have to be sensitive to new information, * especially * when it ruins their spec.
What he wants is stability. You'd be surprised how many very smart people put a premium on that sort of thing, especially when they get older.
An employee with limited options = A more stable employee
NYC isn't exactly a place where you have limited options. You want limited options? Try to find a job upstate.
From perspective the employee it isn't stable. Sounds like he'd get rid of you, if you disagree with anything.
- Questions... people need to ask questions (but not ad nauseam).
- Compensation... 'need a job' should not translate to a desperate wage
Understanding and acknowledging your employees have a life after work is important. The only question I have is how, or do you give out bonuses from your yearly profits.
Basically you've described my serious, competent, self disciplined ex-mil and reserves/NG coworkers. Wait... do I work for you?
Perhaps the takeaway for all of us is that we all need to be humble and at least pretend we need our jobs, even if we're aggressively saving for an early retirement.
As such, I tend to hire those who don't take oneself too seriously. The OP's redflags I feel are corollary to this observation.
Be humble and get shit done.
Your hiring strategy is not "your" hiring strategy: its every mindless, exploitative, and compassionless corporation in the universe. In otherwords, youre overwhelmingly average! Youre contributing to the very problem youre having: no one wants to work for an entity that operates like this.
[0] https://hbr.org/2011/02/hire-for-attitude-train-for-sk
[1] https://www.eremedia.com/ere/hiring-for-both-attitude-and-ap...
Since it's a jr role I'm looking more for evidence that they want to learn than examples of accomplishments.
Aside from the obvious interest in building container orchestration systems, I look for a passion to solve real user problems, not only building a piece of tech.
Bonus points for knowing about Docker or containers or clouds or Golang or security.
More points for meeting users where they are. And the most bonus points for leadership and initiative.
We're particularly looking for someone to lead and/or manage our software eng team building security features into Kubernetes and GKE.
Apply and make your dream come true!
Bear in mind that our hiring process is SLOW, so be prepared for it to take a lot of time. Best of luck!
Also worked as a TE @ MS - had to meet devs & c level execs in startups.
Every time I've applied to Google Canada, I've been told that I'm too late (I get notifications when the jobs are posted and apply asap) and to apply 6 months later or that I'd have to move to SF (really want to work from Canada).
It's my dream to work at Google.
Interviews have practicals where you work on problems you'll see regularly with skills we expect you to have (like writing code, debugging, and task breakdown). Good communication, pairing skills, quick learning, and taking responsibility for your circumstances stand out.
https://jda.com/careers
This shows up in a resume in lots of different ways. For some people it is a rich Github profile. For others it is that they paid their way through college by building websites or apps.
We primarily hire Ruby on Rails developers who work remotely. Seeing in someone's Github profile that they like to contribute to open source and know how to collaborate with other developers are really important.
Advice for senior engineers: brush up your practical programming. If you've been in an architect/leadership role, you may be rusty. Make sure you're comfortable on both whiteboard and keyboard.
If you spent the last 5 years writing iPhone apps, we expect you to know iPhone development pretty well. Memory management is the obvious area here.
Be ready to explain the most recent projects on your resume. Think outside the box - if you wrote code to process messages from a black box, how do you think the black box worked? If you consumed JSON messages, how much can you explain of JSON and JSON parsers? Many projects are so narrow in scope that we can't have a meaningful conversation about them, so be prepared to broaden into adjacent areas.
Advice for new grads and early-career engineers: have some solid, non-trivial code on github (or equivalent) and make sure we know about it. Be prepared to discuss it and explain design decisions. Few do this.
This post is my take on the question - what follows is especially subjective and not representative of shopkick:
Don't put stuff on your resume that you don't know. Or, brush up the skills featured on your resume.
Learn a scripting language, especially if you're a server engineer. People who only know Java/C++ are at a big disadvantage if they have to write code in an interview. How big? Turning a 5 minute question into 35 minutes is typical - and it gets worse. One very smart, very experienced man took 45 minutes on such a question. Of course, don't just port Java idioms to Python; learn Python idioms. Good languages are Python/Ruby/Perl. I think a HN reader probably doesn't need to be told this, but just in case. Properly used, scripting languages teach techniques which carry over to compiled languages.
Server engineers should be comfortable with either vi or emacs. And with basic Linux. Personally I find it astounding that a server candidate would be unfamiliar with ls and cat, but it happens.
I hope this is helpful and doesn't sound arrogant.
After I posted my previous response I realized that I actually know a few emacs keybindings thanks to tmux, even though I've never used the editor. I use a lightly modified vim on my laptop, but I think it's best to learn enough of the defaults (of any application/utility) to speed up your workflow on a new host.
Since we also do private consulting and project-based work in addition to our workshops, we have recently got to talking with our clients about helping them get full-time employment. So I think this post is pretty timely and very relevant to us. Here are a few reasons why we think React is important for the job market.
Lots of companies are choosing React for their front-end these days. It allows your front-end devs to embrace the full power of JavaScript for the front-end -- no more messing around with jQuery and tons of plugins. Sure, there's a bit of a learning curve, like all new things. But there is now a large and devoted community to React and it's only growing. A personal friend of mine convinced his boss to greenfield their entire app with 10,000 lines of jQuery, and rewrite it entirely in React. He was a new hire (and also a great communicator/salesman).
Coding bootcamps are embracing React as well. Since most of these institutions survive year-to-year based on how well their placement numbers are for graduates, they are paying close attention to the trends in development. One could argue that since they are probably more technical than the average recruiter, they may even have a better grip of the pulse. FullStack Academy, of New York and Chicago, recently wrote a blog on why they're moving their curriculum from Angular to React (https://www.fullstackacademy.com/blog/angular-to-react-fulls...). App Academy (SF & NYC) has had React in its curriculum for a number of months (https://www.appacademy.io/immersive/curriculum). And I've personally spoken with alumni of Hack Reactor in SF who said that most students built their capstone project in React (or attempted to).
Is React the best solution? That's arguable, as all things are. It also depends on what you want to accomplish. But for the relevancy of this post -- asking what tech skills people will be hiring for in 2017 -- I would argue that React is going to be one of the top skills. And with that includes...
Redux Webpack Immutable RxJS
As far as backend, the top three technologies that we've seen with our clients are:
Python Go Docker
But of course, all of this is moot without the foundation of strong JavaScript skills. Our students who have strong JS skills pick up React quickly -- those who don't only get confused.
Anyways, if you are skilled in React and other related technologies and you are looking for work, you can always email me: ben at realworldreact dot com with some info about yourself and/or your resume.
A series of 6 small books that cover the JS fundamentals in detail.
* Comprehensive lesson-based: FreeCodeCamp. An easier, piecemeal option with plenty of hints and guides. Disclosure: My business partner is the CTO of FCC https://www.freecodecamp.com/
* Video: JavaScript30 by Wes Bos. 30 Vanilla JS Challenges. Wes is a fantastic teacher and this is his newest series. I haven't gone through it myself but I've taken his other lessons and been pleased, so I feel somewhat confident in recommending this. https://javascript30.com/
* You don't know JS: A series of free lessons on JS https://github.com/getify/You-Dont-Know-JS
* $ Book: O'Reilly JS Pocket Reference. If you already know how to program, this can help you understand JS in a very short amount of time. Obviously you will need to practice to really get it, but this helped me to understand a lot of things very quickly. Great for train commute or downtime reading: https://www.amazon.com/JavaScript-Pocket-Reference-Activate-...
- Developers: We use mostly java, swift, and JS (Angular 2) but we always look for polyglot developers, full stack developers, or whatever you want to call someone that see the language as a mean to achieve a goal and not the goal itself.
- DevOps: Deep ec2 knowledge and experience. AWS certification is a plus
Where are you located? This is something I can definitely do.
Oil and Gas
I was once a Front office dev (Microsoft Stack) for commodity trading house. If you are in USA, Canada, or Japan, I'm interested in learning more about your business.
And we're a consulting company that works with mostly oil and gas companies.
For 2017, I want to hire more engineers with Kubernetes, CoreOS, and Go experience. My team has deep Linux systems administration experience but we've automated ourselves out of most of the day-to-day admin work of yesteryear. Our future hires will be heavily focused on automation. We've already automated builds, testing, deployment, monitoring, and metrics in a Kube/Docker pipeline. I expect to automate load balancing and hardware deployment in 2017. I also expect that we will adapt many of our non-Kubernetes data services for running containerized in Kube.
We may also need a strong lead for a new business unit, a role akin to 'founder lite' — you run a business unit with two others, you have your own burn rate, your own P&L, etc. The strongest skills someone can have for it are former founder experience (aka: broad experience doing lots of things, moving quickly, MVP, etc).
Palo Alto, San Francisco, Seattle.
Bonus points for recognizing the bullshit parade that is the current startup world. e.g.: NodeJS has value, but it's mostly the same wheel we've had for 20+ years. Or that MongoDB's changelog has consisted of standard SQL features for the past five years and that pgsql would have been just fine (had people read some boyce-codd anyhow).
Funny, because it's pgsql that added a JSON data type in response to MongoDB and others.
* It has a revolutionary module system (Common JS) witch allows less coupling, more code reuse and better abstractions.
Try building something with SDL on Windows if you want to see this for yourself.
And modules in NodeJS are truly modular as they contain all their dependencies, even libraries.
The latter: as mentioned in my previous post, this is, to me, a misfeature. Transitive dependencies being encapsulated in a dependency increases the likelihood that those dependencies don't get fixed when bugs inevitably arise in those transitive dependencies. Do not want.
Since all variables are private (function) scoped in JS you do not have to worry about shadowing (overwriting variables), especially when your functions don't have any outside couplings, witch is possible with (common JS) NodeJS modules as modules can be required from within functions or methods. They are just like any variable.
I think I'll have to make a blog post to explain it in more detail. And I encourage you to do the same ...
What do you mean by transitive dependencies ? I don't think there's a concept of transitive dependencies in NodeJS.
If you spend one hour to fix a bug in a open source project, you have probably saved other people thousands of hours of work, money, or frustration. Software is special as it cost very little to copy code, so your one hour contribution can be copied many times creating a lot of value. It's like you would bake one cake once and it could be eaten many times, over and over again.
Alright, I get you now. I agree with you on this that it does allow for that sort of encapsulation--but, IMO, that's a bad kind of encapsulation; having to put fundamentally object-oriented data outside of the object strikes me as a profound routing around serious linguistic damage.
> Since all variables are private (function) scoped in JS you do not have to worry about shadowing (overwriting variables), especially when your functions don't have any outside couplings, witch is possible with (common JS) NodeJS modules as modules can be required from within functions or methods. They are just like any variable.
This, OTOH, is pretty much the same as any language with any kind of encapsulation. Maybe ES modules have finally approached parity, but it's nothing special.
> What do you mean by transitive dependencies ? I don't think there's a concept of transitive dependencies in NodeJS.
Every dependency of your dependency is transitive. Just go look in the node_modules directory of any of your dependencies! If you require X and it requires Y and Z, bugs in its version of Y or Z are suddenly your problem. And its upgrade strategy becomes your problem, too.
OTOH, in something like Maven, saying "no, use my version of this transitive dependency" is very straightforward.
> If you spend one hour to fix a bug in a open source project, you have probably saved other people thousands of hours of work, money, or frustration.
And my client doesn't care. If I'm working on my stuff, sure, I'll do that if it's the most efficient way to solve my problems. My clients do not give a single shit about this, though, and I have to build things they can deal with, not me.
So this is at best a misfeature. Primarily a bug.
Take for example, Walmart Labs move to Node.JS + React [1]. The rationale is quite obvious here. It's a step to distance from the corporate portrayal of "Walmart" and create an image of a nimble, developer-friendly team (There maybe other important reasons, but I'd assume good PR mattered a lot). Contrary to what HN may suggest, the first thing that exhilarates a developer (the early ones to say the least) isn't the business, it's the tech.
[1]: https://blog.hellojs.org/walmart-labs-releases-electrode-mov...
So when I see a job posting advertising those I know the people in charge have no clue in what they're doing and treat developers as janitors.
Or as pg said: "The more of an IT flavor the job descriptions had, the less dangerous the company was. The safest kind were the ones that wanted Oracle experience. You never had to worry about those."
don't forget the tennis courts
I've definitely had people that interviewed well that just wanted JIRA tickets fed to them immediately upon starting. It's very hard to figure out if someone will seek out and make improvements consistently from the basis of conversations.
(I'm in ops so there's rarely a body of code available they can share for how they work, either.)
I mean, what ambitious person would like to worse in less that best job available on the market, for best possible money?
Edit: I'm not trolling, sorry if my post sounds insincere. If there's a good fucking story behind your statements, I want to hear it.
IMO somewhat uninformed opinion (longtime dev on two of the biggest platforms, played a bit with node etc a few times) the Javascript ecosystem has seems to have numerous issues. Here is my impression:
- being equally bad or worse than php in a number of ways (I used to write php, the right way ; )
-to: having bad dependency management
-to: the complete ecosystem being in a churn, always. Like if php constantly was having the php4-5 transition or if python 2 and 3 was simultaneously in a flux.
-to: being pushed for the wrong reasons
Same goes for gradle (and I guess a number of other hip technologies):
I start looking into it and it turns out it isn't even faster! The unique selling point of gradle seems to be that it is not xml-based or something.
Thanks but no thanks. Not interested.
In fact just yesterday I commented on something and said: sounds cool so I will avoid it for now. I'll use the old way, get it done and then add it on a rainy day (or better: a rainy night) after funding is ok or whatever.
Edit to match your edit:
I have replied as well as I could. I didn't even notice it was you until I had posted.
That said I think you make your own life worse by referring to others as "cynical, older person" and stating without doubt that some "... things that make a pretty small difference in the grand scheme of things" - especially that latest part makes it look like you have already made up your mind.
Oh, and as I mentioned last time: I'd stop swearing here, at least for small stuff like this ;-)
I use node.js, but doing things the "node.js" way is just crazy. You don't make a higher level project depend on a package manager
"Sounds cool so I will avoid it for now, I'll use the old way, get it done and then have fun with it after we solve the problem"
I actually feel that there's some great advice here. I mean, great "fucking" advice. People in my community tend to jump into things that are new and shiny, and it makes me feel that I'm missing out sometimes, or that my tools aren't good anymore. Oh, React is out and is past .1? Time to change my entire coding style. I guess if you are familiar with a way of doing something that works, get it done that way, then improve it later.
Regarding your other advice -- I'd rather call people "old and cynical" and give them a chance to show me why I'm wrong. Otherwise, I'd just stay wrong. I'm actually glad that you take the time to try and help people like that, I think I'd get along well with you had I known you in person.
That's under your control, right?
> I'd rather call people "old and cynical" and give them a chance to show me why I'm wrong.
If you address people respectfully, you will get more fruitful responses.
An insult is rarely the best way to start a conversation.
Great way to end a conversation.
[1] - https://projects.eclipse.org/projects/tools.buildship
Compared to mvn or ant or something else or compared to not using a build system?
Honest question. I'm trying to figure out if I have missed something when I dismissed Gradle last time.
I have also done some C++ dev work with Gradle. It's not ideal, but having one build system that handles differing platforms was great.
Which version of Gradle were you using last time? Gradle 3.0, released 3 months ago, offers Kotlin as the preferred language for scripting builds and writing plugins, instead of the ageing Apache Groovy which is still available for those who still need it.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newswelcome.html
We detached this subthread from https://news.ycombinator.com/item?id=13165043 and marked it off-topic.