Right. You don't impress people by saying "I'm a good communicator." You impress them by... communicating well.

Saying "I'm a good communicator" is the most succinct and clear way of communicating that one is a good communicator.

The recipient needs only read 4 words to get the message.

More seriously, the most that reading "I'm a good communicator" tells me is that the writer can form sentences reasonably.

Succinct? Sure, but it's still so broad. When I'm working with someone, I would appreciate a troubleshooting message of "The Flob server is saying clients don't have the right Gruffin anymore." instead of "Flob isn't working."

Obviously this depends on context, but choosing where to be succinct is key. My project manager would much rather hear "Flob is down for half the users - we'll have a patch tested and deployed by tomorrow afternoon" than "Flob broke, and we're fixing it".

"I have a proven history of writing clear and efficient end-user documentation" and "I'm someone people enjoy bouncing ideas off of" give me more confidence in someone's communication skills than "I'm a good communicator".

Generally I'll assume you're a good communicator until you show otherwise.

That's exactly what I always did and I can tell you the conclusion of that experiment is that precisely 0% of recruiters/HR/bosses did read my cover letter.

As far as messaging you need to show accomplishments? Translate to measurables like $ grown, $ saved, % improved, % eliminated, etc. Those pop out that you are goal oriented.

I've found the generalizing duties and skills doesn't get much attention.

You're correct about generalizing duties and skills. Bullet points on resumes that talk about non-specific day-to-day responsibilities are mostly filler.

This. A co-worker interviewed a guy last week who had 3 pages full of bullet points and when he asked him about his experience with any of them, he gave us some generic response like, "We used Java on project X that did Y". List 6-7 core skills; or better yet, list projects you worked on, the stack you built it on, and a very brief summary of how you kicked ass on it.

He has example projects on his site, which is great; most people don't even have that.

When I go into an interview as a developer, I always go in with a running example of a project that I built, with source code. Towards the end of the interview I'll bring it up: "I brought along a project I built; I'd love to go through it quick with you." At which point I go through the UI to show what it does and then open up the code to review the architecture and anything clever I did within the code itself.

Note that this all happens in about 5 minutes; no one wants to sit through a 30 minute demo.

Do you have any tips on how a dev can quantify his/her work in an easily digestible format like all the resume books suggest?

Scalability numbers and measurable performance improvements are relatively common. So if you built something that is able to handle n requests maybe.

The amount of revenue generated by a feature is clearly tough - but you might be able to find out new subscribers since the feature was introduced. Even if you can't, just saying you built a certain feature is probably enough in most cases.

It really boils down to unique, one-off accomplishments for me. Specificity. That code that runs millions of times - tell me the product name, what that product does, what your code does, and what tools you used to build it. Even if you can't point to a quantifiable figure, the specificity gives you some credibility.

Every job I have is mostly due to referrals. Someone putting a good word on behalf of you means a lot.

Also don't fire and shoot. Target like a sniper.

If I tried to get an interview from this company through the job fair at my school, I would have most likely not even gotten a phone interview. The only thing, I haven't told any of my coworkers who referred me. I'm not totally sure how prepared I am for this work and I wouldn't want any poor performance to reflect back onto him.

- Automated the manual week-long test and QA procedure for critical aerospace devices into a daily 1-hour automated routine.

- Increased application performances by over 9000%, allowing us to save 1M million a year in AWS server costs.

- Ensured we delivered consistently and with due diligence, every single day, month over month, to our 586 millions users.

- Interviewed and graded 23 candidates.

# Typical stuff you'll find in my resume.

As you can see, there are plenty of numbers to talk about, no matter your position. Costs, time, users, revenues, latency, percentage, improvements, progress, duration...

You just need to think harder about what you've done and put numbers on it. ;)

It doesn't have to be perfect, approximate and round if you have too.

From what you say, it sounds like that whatever you did was driven by (initiated by, started because of) (a) technical need (b) order from above or (c) guessing. However, what people mean by "show the impact" is that they are looking for someone who has already done work mostly driven by their observations of business needs, their initiative to improve specific business results by technical means.

If you had no idea "how much revenue these features are going to help bring in or how many sales they'll generate" then you were performing a different role/function than e.g. a person who looked at a need to increase sales (or whatever else was the main business/strategic goal of their company at the time) and figured out a software feature to achieve that. Perhaps you are capable of more than just implementation, but how would a potential employer know? It's not like they'd just ask you, they want to see evidence that you have done this before, that you have been not only implementer of ideas but initiator of changes driven by your personal understanding of business needs - not matter how your role was called or what your nominal job description did/didn't include.

I think this is important, in a sense personalizing it for the company, and also the specific position you are aiming for. rather than aim for the entire goal net aim for a specific cross stitch within the net.

on a side note, all of the comments of others offering help I find absolutely beautiful and it makes me happy to have found this community of incredible people!

I'm a huge advocate for automation but there is such a thing as too much.

If you need more context, I just started learning web development and want to start building some interesting projects that could help me get a job.

1) Work experience. Let's face it, this always looks good to everyone looking over your resume. We all know that people hiring for an office have a bias for work you do in an office. I'm as guilty of it as the next guy.

2) Side projects. For me at least, starting stuff from the ground up (no matter how silly or niche) shows me the kind of code you write in your free time, which is a much better measure of your ability (but possibly a less rigorous measure of your success) than what you do at work, where you're constrained by deadlines, code reviews, and "best practices".

3) Open source contributions. This one is trickier; usually when you contribute to Open Source projects, you're doing small pieces of the big work that needs doing, and there isn't much decision making/architecting going on. Speaking as someone who's currently trying (and failing....) to get into Linux kernel contributions, 90% of the issues you're going to come across that are within your abilities to fix are the kind of thing that a more experienced dev could do in 20 minutes, but doesn't have the patience to sit down and do it (due to being busy with more important/pressing work). So, the vast majority of the work you'll do (especially early in your career) is going to be bound in scope by your lack of experience, and won't be as impressive as engineering something from scratch.

In general, WRITE CODE. WRITE LOTS OF CODE. And show off whatever you can. And try to follow best practices, e.g. using CI/CD, writing good tests, using proper style, designing and documenting your architecture, etc.

1) Do you understand databases, or did you choose an easy project that lets you avoid knowledge of databases?

2) Do you understand how to write code on the serverside (either PHP, or Node, or Java, or Django, or something like that)?

3) Do you understand CSS/HTML/Javascript, or did you choose a project that makes it easy to avoid these things? Bonus points for React or similar framework.

4) If you are looking for work as a frontend developer, I would also include things like, "is the website attractive? Is it easy to use/user friendly?"

5) Do you know processes......git, Jenkins, AWS deployment, etc?

You don't have to be perfect in all those categories, of course, but the higher you score in each of them, the better.

Of course you can go back and refactor old code (which you probably will if you keep repos public as your career advances), but have at least a few completed and fully functional projects to show.

Then he ought to be spending 90% of his effort finding those narrow corner cases instead of sending out 1,000,000 applications.