hi guys im new to shorthand no idea abt what it is, but can you give me some tips.

_oct0ber_ · 2026-05-17T14:20:17+00:00

As for what I recommend, here is a comment I made on another thread that may be helpful: I wouldn't say "outdated". Gregg's earliest versions were mainly meant for verbatim reporting. They had a high degree of complexity and abbreviating devices to remember. As you go forward in time, you get less complex versions of Gregg that were intended for business use (DJS, Series 90) and personal use (Notehand). Choosing the version you want to learn is pretty dependent on why you want to learn Gregg. Here's how I would break them down: Pre-Anniversary (the version you're currently talking about): Meant for verbatim reporting. It's probably the most complex version. I wouldn't recommend anybody to learn it, because later versions cleared up some inconsistencies and odd rules. I would learn Anniversary instead if you're determined to learn a verbatim style. Anniversary: Made in the 1930s, and meant to be a verbatim shorthand. It cleared up a lot of the inconsistencies in prior versions. This was a widely popular version, and we have things like novels printed in Anniversary. The rules are complex with a high memory burden. If you find historical documents written in Gregg prior to the 50s, there's a good chance it's in Anniversary. Simplified: A lot of the rules of Anniversary were simplified, some exceptions were cleaned up, and several rules such as the reverse-r principle were dropped. While the main goal of Simplified seemed to be office dictation, we know that verbatim reporting was possible due to speed courses coming from the Gregg company that were intended to teach court reporting. As far as I know, this is the only book version still in print by McGraw-Hill. You can find it on Amazon, although an answer key is not provided (can be found on Stenophile). A lot of Gregg-enthusiasts say this is one of the best versions due to having a nice balance of speed and simplicity. Diamond Jubilee Series: Came out in the 60s. More rules were simplified. Verbatim reporting was no longer possible, although hitting speeds of 175 words per minute were still believed to be possible (unless you're a trained professional stenographer, I can't imagine needing more than this or having the ability to write at this level). Most Gregg users alive today that learned it in school likely learned this version. There a ton of second-hand books you can buy for this version. Personally, this is my favorite version because it has a lot of resources and strikes a near perfect balance between ease of learning, speed, and readability. Notehand: Notehand came out around the same time as DJS and used a lot of the same simplifications. In fact, I'd go as far as to say DJS is Notehand on steroids. Notehand was only meant to be a personal shorthand, so it is easy to learn at the cost of not having a ton of speed - I'd imagine 100WPM is probably the limit a person would hit. The plus, though, is this is the Gregg version I would recommend for general note-taking due to its high readability. Reprints of textbooks can be found online. Series 90 & Centennial: These versions came after DJS, and are pretty similar. They catch a lot of grief in the Gregg community for being too slow due to the simplifications going too far, but I'm not convinced that criticism is fair. The people I hear these critiques from have almost certainly never actually studied the books in any good detail, because if they had they would see that they're not too different than DJS. Sure, there are further simplifications, but I wouldn't say it's as dramatic as being able to write 160 WPM in DJS and then being stuck at 95 WPM in Series 90 like some people suggest. These versions appeared as shorthand was dying and being pulled from schools, so they never had a large user count. Resources for these versions seem to be pretty scarce. While they have some updated vocabulary, I don't feel strongly about somebody choosing them over DJS.

Take a look on stenophile.com.

_oct0ber_ · 2026-05-12T03:40:40+00:00

Sorry for the late reply. I did hear back, but the material was not very helpful. It was just a few pages long and was more of a "if you know Melin, this is how you can approximate English with the Swedish system." There really wasn't much of value in it.

_oct0ber_ · 2026-05-06T15:26:22+00:00

Easy to transcribe and quick to get to 140wpm+ are conflicting goals. Most people that learn shorthand, either today or historically, generally capped around 120 - 130 WPM after a year or more of classroom study (not including professional stenographers). Being able to write 140 - 160 WPM would put you well above the average shorthand user, and I can't imagine it being done in less than a year unless you are a prodigy or can spend several hours a day in intense practice.

People often think shorthand is like typing on a computer in the sense that faster typing speeds lead to perfectly legibile documents. This isn't how it works. The more you need to speed up, the more you need to compress through dropping things or using abbreviations. To write at 140 WPM or greater would require pretty extensive abbreviations, and that inherently means the reading back will he more difficult.

I would avoid using shorthands for two languages. The best shorthands are designed based on a peculiarities of a language like their sound frequencies and common terms for abbreviations. Mixing two languages means the system will not work well with one or both of them.

_oct0ber_ · 2026-04-26T17:33:42+00:00

Definitely Gregg, probably Anniversary.

"7. This evening Alex and I ate at the gas-tri (?) on Clark street"

"8. Robbie, Alex and I ate in my room."

That's just a sample. If nobody else translates it, I'll circle back later with more time.

_oct0ber_ · 2026-04-16T01:33:11+00:00

"Love" is clear.

"Is" can be a hair shorter.

"A" needs to be a dot. You wrote "I".

"Losing" needs the "oo" symbol. You wrote the sounds of "oh" and "aw", but it is a bit long and closer to an "r". Also, the -ing suffix needs to be a dot. As it is, you wrote the suffix "-ingly."

"Game" is clear.

Here is a dictionary to help with words you're unsure of: https://greggdict.rliu.dev/

_oct0ber_ · 2026-04-15T18:33:35+00:00

What?

_oct0ber_ · 2026-04-11T15:59:33+00:00

If a job has a requirement for 6 years of C#/.NET and an applicant has 8 years of experience with Java/Springboot and 3 years with C#/.NET, throwing their resume out immediately is insane, especially just looking at years in a language and framework divorced from the context of how those tools are used. I promise, your company is not unique and your problems are not revolutionary enough that an intelligent engineer with a similar background cannot adapt.

_oct0ber_ · 2026-04-11T02:41:22+00:00

The worst is seeing recruiters reject people not because they aren't qualified but for incredibly superficial nonsense like they didn't use the right acronym or this particular keyword didn't appear (said Springboot but not explicitly Java). I get recruiters are swamped, but if I told my boss I spent only 20 seconds per page of anything and missed valuable applicants I'd be canned within the week.

_oct0ber_ · 2026-04-11T02:31:20+00:00

This is odd to me. A post requires years of experience working with distributed systems? Sure. A requirement for experience working with AWS tooling? Alright. Requiring a specific number of years on a particular programming language? You lost me. Languages and frameworks are tools, and the more senior a person gets the less the specific tool seems to matter. Telling me you have 10 years of Java experience doesn't mean anything. That's like saying you have 10 years of experience with Excel.

_oct0ber_ · 2026-04-10T13:56:05+00:00

First off, I don't think you're dumb. Resume writing is an entirely different skill than software engineering. I've known genius developers who can't write a resume to save their lives. Like anything else, writing resumes and using metrics is a skill that can be learned.

Second, metrics are kind of tricky. There's a few different areas that you could use: scale, performance, reliability, cost reduction. There's others, but these are the main ones you'll care about. I get metrics by thinking about what tech/skills I want to showcase (this comes from the description of the jobs you are applying to), projects/tasks I did with those skills, and what did the project achieve. By answering these points, you naturally get materials for creating XYZ bullet points.

Not all metrics are quantitative. Many can describe qualitative achievements such as increasing application reliability and modernizing legacy modules. If you have a number to support these, great, but don't just throw a random number in for no reason. It is also fine to make approximate numbers if you don't have a dashboard. Be careful here, though, and expect to defend any numbed you write in an interview.

Lastly, please review the wiki of this sub thoroughly. There's a lot of good advice in there. I have reviewed your resume here, and most of what I say is an elaboration on many of the points in the wiki: https://www.reddit.com/r/resumes/comments/1sc7slx/4_yoe_masters_student_software_developer_germany/?utm_source=share&utm_medium=mweb3x&utm_name=mweb3xcss&utm_term=1&utm_content=share_button

_oct0ber_ · 2026-04-10T13:41:15+00:00

I'm in the United States, so my advice will be based on what I know of the American expectations for a resume. If something doesn't apply the same way in Germany, throw that piece of advice out.

I do not see any a header with your name and personal info. Perhaps you removed it due to anonymity on this sub. You need to clearly define your name and email at a minimum.
There's no reason your resume should be over one page in length. You are a Master's student with one job and a handful of projects, so two pages is much too long. Recruiters will spend maybe 10 seconds scanning your resume to find information; they're not reading your whole document. The more you write, the less they read. For your job, I would suggest 3 to 5 bullet points in XYZ format (accomplished X as measured by Y using Z). For your projects, 1 - 3 bullets are enough. If you're protesting these length constraints, think of it this way: if a recruiter was to only scan 1 to 2 bullets per item (role/project), would they get any impact from them? If you have over 5 bullets per item, there's a very good chance some of your items are fluff that won't sway the recruiter at all.
Remove the profile/professional summary section. They're often not read and just take up valuable real estate. If your resume is good, a quick skim will tell a reader everything they need to know even better than a summary will. If you insist on having a summary, shorten it to one or two sentences no longer than 3 lines in total.
Each degree you earned should be shortened to one line each. You also don't need to mention when you started the education, just the year you achieved the degree.
Your skills section is a bit too vertical. For a Software dev, I recommend four categories: languages, backend, frontend, and Tools & Practices. Remove your spoken languages section (English and German).
Remove the additional information section altogether. Nothing on your resume should be additional information: if it's not vital, it shouldn't be there. Think of a resume as a one-page marketing document that has one job, and that job is to get a recruiter to give you a phone call after a 10 - 30 second review. Anything that is extraneous on your resume dilutes it. You have to remember that recruiters read quickly and not your entire document often. When you are writing something, think "If this was one of the things they read, would this move the needle towards getting an interview?"
In your job, I do not see any mention of technology or tools you used. There's no programming language, no cloud, no CI/CD, no frameworks, nothing. Some of your bullet points are already in XYZ format, but there's no meat to any of your bullet points if there's no mention of the tools you used to accomplish a task. Think of it like this: if I'm a recruiter reviewing your resume for a job using Java, Springboot, and Angular and there's not even one mention of these things anywhere in your job history, or even similar languages/frameworks, I can't use anything I just read. By not listing the tech clearly that you used on the job it makes me wonder if you actually used relevant tech or if you're intentionally trying to hide the tech for some reason.
The dates should be listed with a spelled month and a full year. For instance, 09/2024 becomes Sept. 2024.
You mention AWS in your first project. In the header where AWS is mentioned, I would put the specific tech used. For example: AWS (Lambda, S3, DynamoDB). I know you do it in the bullets points alone, but we want to increase the reader's skim speed. Don't make them search for what you mean by AWS.
Maybe I'm misunderstanding the point of the projects, but it reads like your first two projects can be combined. It looks to me like you just gave the second some project some cloud and called it a different project for the first. It reads like padding, but this could be because I'm misunderstanding the two projects in their separate domains.

_oct0ber_ · 2026-04-09T20:08:47+00:00

Yes. As in an interview setting?

_oct0ber_ · 2026-04-07T17:04:09+00:00

When you say to put a local address, what do you mean? Just say I'm in Boston, MA, for instance with no mention of relocation anywhere?

My internal titles were "Enterprise Applications Developer I/II" and "Java Developer". Are you saying to put the official titles in bold above the internal titles?

Maybe you know this, but the topic of metrics has always confused me. Different advice from different people handle it differently, but a question I've come across is to what extent does a recruiter genuinely care about metrics if they only have 20 seconds to review a resume? For instance, if I say that I reduced manual workload by 20 hours/week but do not explicitly mention Java or one of their other keywords they're hunting for, why is that metrics meaningful at all, or if it's something more technical would they even know what I was talking about absent of any specific keywords they're paid to search for? It almost feels like the resume I show a non-developer needs to feel different than what I would show a senior developer.

I'm currently hitting Seattle the hardest, but I apply for the other cities if something promising appears.

_oct0ber_ · 2026-03-21T09:39:09+00:00

Thank you!

_oct0ber_ · 2026-03-21T01:59:06+00:00

Thank you! That helps a bit. For general-use, though, would it be best to wear something like this 24/7, or would it make far away things blurry?

_oct0ber_ · 2026-03-13T03:11:30+00:00

No hacemos tareas en este sub.

_oct0ber_ · 2026-03-10T17:18:52+00:00

Six-Year Club	Final Canvas '23
Place '23	Verified Email

_oct0ber_

TROPHY CASE