How to write your own derive-macro in Rust

Derive macros are one of the three procedural macro types in Rust. Visit the rust-reference to learn more about their differences and use cases.
Once implemented, they are used to add extra functionality to your code, without having to write it. But simply through adding an “annotation” if you will, to the source code. And the compiler creates the code (at compile time), in the way the author (we) have described it.

One derive macro rustaceans might be familiar with, is the #[derive(Debug)] macro which provides a default implementation of the Debug trait. When added to a struct or enum, a text representation gets implemented for that data structure, which can be used in debug logging for example.

And we are now writing our own derive macro!

The ToUrl macro

⚠️ This is not a macro for production! ⚠️ It is meant for training purposes only.
The entire code is on github under

ToUrl is supposed to work as follows:

When the #[derive(ToUrl)] is added to a struct (only structs are supported) then a
to_url(&self, base_url: String) -> String method gets implemented for that struct.
When called with a URL-String (the url_base), this method will first add a (the start of a url-query-section), to the given URL. It then iterates over all fields and adds them in the form field=value, to the current URL-String.
If the struct has more than one field, the pairs are concatenated with an & (ampersand).
Vecs are treated slightly special (only one dimensional Vecs are supported):
Their values are all joined with a url-encoded space character (%20).

Usage Example

// This example would be in a different crate than *to-url* (because proc_macros must be defined in their own crates)

// Annotate a struct with ToUrl
pub struct Request {
    response_type: String,
    client_id: String,
    scope: Vec<String>,
    redirect_uri: String,
    state: String,
    nonce: String,
// Create an instance of that struct
let dummy_req = Request {
    response_type: "code".to_string(),
    client_id: "1234andSomeText".to_string(),
    scope: vec!["openid".to_string(),
    redirect_uri: "".to_string(),
    state: "security_token0815".to_string(),
    nonce: "4242-3531".to_string(),

// Calling the to_url-method on the instance in the following way...

// ...would create the following string:

Implementation of the ToUrl derive macro

Create the library with cargo

// from the command line run
cargo new to-url --lib && cd to-url

configuration (Cargo.toml)

The dependencies and their versions are as follows:

proc_macro = true

syn = { version = "1.0", features = ["full", "extra-traits"] }
quote = "1.0"
proc-macro2 = "1.0"

Note that under lib we have specified that we want to create a procedural macro crate. As of writing those have to live in their own crates.

The function definition

Proc macros are functions that have to be annotated with #[proc_macro_derive(NameOfYourMacro)]. The function receives a TokenStream, which is an abstract token representation of the source code, on which the macro has been added. It’s not quite the code that we wrote anymore. But also not actual machine instructions yet.
And procedural macros can modify that TokenStream, in order to create new/different code, again in form of a TokenStream.
In our case we call the macro ToUrl.

pub fn to_url(tokens: TokenStream) -> TokenStream {
  /* implementation */

Parsing (syn) & Generation (quote)

Inside the function we will make use of two amazing crates. For parsing we will use syn and for code generation quote. With parse_macro_input! the TokenStream gets transformed into a DeriveInput which is helpful for walking the tree structure and provides additional helpful methods. To retrieve the name of struct that we want to derive our macro, we safe the value on the indent field of the input.

pub fn to_url(tokens: TokenStream) -> TokenStream {
    let input = parse_macro_input!(tokens as DeriveInput);
    let name = input.ident;

    /* rest of the implementation */ 

To get to the fields I have chosen to match on the data field of the input. It looks a bit funky, but if you follow the types through the documentation, starting with the DeriveInput, you might notice that I walk the structure, only mentioning the parts that I am interested in. The part that we don’t care about is ignored with the double dots (..). The fields are of type Punctuated<Field, Comma> and live on an instance of type FieldsNamed.

    /* implementation before is skipped */

    let fields_punct = match {
        Data::Struct(DataStruct {
            fields: Fields::Named(fields),
        }) => fields.named,
        _ => panic!("Only structs with named fields can be annotated with ToUrl"),

    /* rest of the implementation */

Here comes the rest of the implementation inside of our derive macro function. The part where the code is generated. The modified code gets passed back to the compiler as a TokenStream.
The part, that concatenates the fields and their values, will be looked at further down. For now, it is abstracted away as a call to query_from_field_and_value(..). Just know that it gives us an Iterator over TokenStreams.

  /* implementation before is skipped */

    let query_parts = query_from_field_and_value(&fields_punct);

    let modified = quote! {
        impl #name {
            pub fn to_url(&self, base_url: String) -> String {

                let url = format!("{}?", base_url) #(#query_parts)*;


quote! is a macro that lets us construct full TokenStreams, which the compiler understands, from the text we write inside of it. One must of course adhere to the rules of quote!. But it is much more convenient than constructing parsable trees by hand.
In the impl line, we use the name variable, we have defined on the very top of our function. Bindings within scope but outside of the quote!-macro-call are referenced by prefixing them with the pound symbol (#). At compile time #name contains the name of the struct, that our macro gets derived for. In the example that is Request. So the impl-line actually gets expanded to:

impl Request {

Note: This version of the macro does not take into account that the struct might have lifetime annotations like <‘a>. If we would like to support structs with and without lifetimes, they have to be taken into account in the code generation.

Before we move on, let’s disect the line
let url = format!(“{}?”, base_url) #(#query_parts)*;
The left hand side is merely defining a binding with the name url. To which we assign the right hand side. The first section of the expression on the right, the format!(“{}?”, base_url) will evaluate to a String. Resulting in base_url extended with the question mark, the beginning of the query-section. In the example this part would turn into:
Now comes the fun part: #(#query_parts)* which combines the field=value pairs into one String.
In quote! we have the possibility to repeat patterns by using the library’s interpolation-syntax. We are using the form #(#var)* where #var will turn into some expression and we repeat this pattern until there are no more elements in that #var. In our case (remember above: query_from_field_and_values(..) returns an Iterator), the repetitions end when the Iterator is exhausted.

Constructing the Url

How does the URL-String come together? Have a look at the beginning of the returned quote!-call in the else block of query_from_field_and_values(..).

fn query_from_field_and_value(
    fields: &Punctuated<Field, Comma>,
) -> impl Iterator<Item = proc_macro2::TokenStream> + '_ {
    let fields = fields.iter().enumerate().map(move |(i, field)| {
        let field_ident = field.ident.as_ref().unwrap();
        let delim = if i < fields.len() - 1 { "&" } else { "" }; // Add an & between two field=value pairs
        if is_vec(&field) {
        } else {
            quote! { + &format!("{}={}{}", stringify!(#field_ident), self.#field_ident, #delim) }

The implicitly returned quote!-section in the else-case starts with the “+” operator. After that follows a call to the format!-macro, which will evaluate to nothing more but a String. This means that on every iteration over the pattern #(#query_parts)*, we get “+ field=value” which gets concatenated to the existing String, by using “+”. No magic. Just adding Strings together.

// format!("{}?", base_url) #(#query_parts)* expands to something similar to this:
"my-dummy-url? + "response_type=code" + "client_id=1234andSomeText" + ... + "nonce=4242-3531"

Three more things are worth mentioning.

  1. We use the stringify! macro. It turns the given token(s) into literal text. Which means our field-identifiers get turned into their String-representation. If we would use #ident.to_string() the compiler would try to find a variable with that name (e.g. client_id) to call to_string() on it’s value. But of course would complain that there is no such variable.
  2. We use self inside a function without having it as an argument! 😯 Pretty cool right. At least it took me quite a while to notice that in some other examples. It sure gives a lot more flexibility to separate some logic into its own concise section.
  3. This example uses the format!-macro a lot and is tailored around String concatenation. This means field-types have to implement std::fmt::Display, the trait that provides the implementation of to_string() for a type. This makes ToUrl quite limited. Even worse, there is no error-handling around that fact. But like I said in the beginning: this is a training implementation.

And thats pretty much it.
There is still a is_vec() and a join_values() helper-function. They don’t do anything new regarding the derive-macro-topic and they are pretty specific to this concrete example (which has questionable applicability in it’s current form).
Never the less, here is what those two look like (I have implemented them outside of the macro-function but in the same file). Like mentioned above, the entire ToUrl-macro-code is also available on github.

fn is_vec(field: &Field) -> bool {
    match &field.ty {
        Type::Path(TypePath {
            path: Path { segments, .. },
        }) => {
            // segments is of Type syn::punctuated::Punctuated<PathSegment, _>
            if let Some(path_seg) = segments.first() {
                let ident = &path_seg.ident;
                return ident == "Vec";
        _ => false,

fn join_values(field_ident: &Ident) -> proc_macro2::TokenStream {
    let len = quote! { self.#field_ident.len() };
    let vec_values = quote! {
        //let len = self.#field_ident.len();
        self.#field_ident.iter().enumerate().fold(String::new(), |mut vals, (i, v)| {
            if (i < #len - 1) {
            if (i == #len - 1) {
    quote! {+ &format!("{}={}", stringify!(#field_ident), #vec_values)}


Proc macros in Rust, especially the derive macro in my opinion, are fantastic concepts that let the developers extend the language in very versatile ways. They are heavily used in many crates and make our lives as library users much easier.
They are also a rather advanced topic and not necessarily coined towards Rust beginners. Nevertheless there are extremely helpful crates like syn and quote with great documentation.
Precious resources are also the proc-macro-workshop by David Tolnay on github.
And my favorite, the one that actually took away my scare around proc_macros:
Procedural Macros in Rust Part1 & Part 2 by Jon Gjengset, where he works through some of the exercises of the before mentioned proc-macro-workshop.

That’s it! I hope this was helpful or interesting to you. Thank you for reading.



My Journey to Becoming a Developer – A Roadmap (with side tracks)

This post could be seen as a syllabus for CodeNewbies. Although I mainly wrote it as a summary about what I have learned and which roadblocks I had to overcome on my journey towards becoming a developer so far. If you are a newcomer and just want a quick tip on where to start: have a look at topic 6 “Learning HTML, CSS, JavaScript Round 2” or the “Conclusion” at the the end of this post.
This post lists all the steps I took, when I took them (some of them happened simultaneously) and how much time I invested. You shall find recommendations as well as routes you might wanna avoid in order to stay on track.

1. Figuring out what to learn
(2 weeks: 23 Jun 2017 – 08 Jul 2017)
The beginning of everything, the root of my desire to being able to code was: “How the heck do people talk to computers?”. Someone might have told me: “Java is used a lot for that”. So I started to learn Java on a mobile app (or at least I was trying to). With absolutely zero programming experience, this was not really working out well for me. And even though Java is or at least was used heavily throughout many tech-stacks (e.g. Android app development), I would not recommend it as a point of entry for beginners. Maybe they person recommending meant JavaScript, which is a completely, fundamental different programming language and would have been way better to start with, but what did I know at the time. Anyways, question now for the goal-less coding-padawan: “Back to square one. What should I learn in order to speak computerish?….” Someone else told me to “Learn HTML! Then CSS and JavaScript.” I was like: “But I don’t want to build websites! That’s what people use Wix and stuff for now, riiight?!” How incredibly wrong I was. The possibilities you have with just these three “web” technologies/languages are sheer endless. Most cool web-apps look and behave based on them.

2. Learning HTML and CSS with a mobile app
(2 weeks: 12 Jul 2017 – 28 Jul 2017)
Despite the rocky start I had with Java, the mobile-app-learning-experience was fantastic. I used SoloLearn. Where you can read and solve quizzes, while waiting for the bus. Great! So I worked through both curriculums and really got fascinated with what you could or had to do to put text, pictures, forms, STUFF on the web. So I was ready to go ahead and make something, correct? Absolutely NOT! Clicking on a mobile app is great to get an idea but won’t cut it.

3. Installing a code editor…
(a couple of hours, including research: 20 Jul 2018)
…which I should have done from the very beginning. It can be so easy to install and use an editor and is so incredibly helpful and more fun to practice in general. Theoretically you could use any plain text-writing-tool (Microsoft Word does not work btw.). But please do yourself the favor and get a real code-editor. I used Brackets in the beginning but later switched to VS-Code (by Microsoft) which is highly recommended by successful, known developers (e.g. Wes Bos and Scott Tolinski on Both editors are free of charge. There are many great alternatives so I hear (but have not tried them myself) like: Atom or SublimeText. When in doubt: go with VS-Code. Little trivia: VS-Code and Atom are both ElectronApps. Which means, even though you download the program and run it offline on your desktop, their main building blocks are HTML, CSS and JavaScript. Isn’t that exciting?
I also got a free codepen account at that time. It’s an online editor, where you can write HTML, CSS, JavaScript and see how they interact with each other, all in the same browser window. Without downloading anything. This is so useful and fun to protoype and experiment with, I can’t even express it in words. You don’t have an account, yet? Get one now! Seriously! – I’ll wait.

4. “Dipping your toes in!..”
(3 weeks: 21 Jul 2017 – somewhere in September 2017)
…as the like to say. I tried out typing some basic html in my editor and mainly followed Shay Howe’s HTML-CSS-Tutorial. Again, something I can highly recommend, even if, as of writing, it does not cover CSS-flex-box and CSS-grid (element positioning techniques) yet. This tutorial made me understand how to structure content using HTML and how to apply some CSS to set how this content should look. Parallel to this I started and finished the SoloLearn’s mobile-app-curriculum for JavaScript. “NOW we’re talking” I thought. “Here it is! A real programming language with calculations, loops, conditions – things you tell your computer to do!” I immediately knew, that this is more of what I wanted to learn in the first place. Was dipping my toes in HTML and CSS a waste of time? Nooooo, both are really important and I need to get a lot better at them still. Because without them, most programs that do stuff (like command-line-tools) just look like plain text with one font, one color, in one size. One thing was certain though. I wanted to code logic! Without having an idea or even a conceptional understanding. Sooo back to the research: “Hey Google,

  • what are some good coding projects for beginners?
  • how to learn basic JavaScript?
  • where to start, please just tell me the right way, pleeeeaaase.”

5. Reading a book
(many weeks: 29 Jul 2017 – someday in 2018)
My researches lead towards a book. Books are a generally a great resource for everything, are they not?. And with platforms like Packt there is a lot of awesome content out there for just a few bucks or even for free. Actually it feels like way to much you have free access to. Because sooner or later you’ll find yourself sliding down a steep, dark rabbit hole, where you jump from topic to buzzword to definition to the explanation to that definition to the next topic and so forth. What helps? Taking a breath, telling yourself “I can use a TV, a microwave, a refrigerator, all without knowing how it actually really works internally and never got seriously injured.” So nothing to worry about just yet.”
One book that is recommended as an introduction to JavaScript throughout the community is Eloquent Javascript. It is a great, free book. Is is for beginners you ask? NO and three times NO. I do really love it and read the 2nd Edition in when I started out learning and finished reading it a second time (3rd Edition) in Oct 2018. The second time around though, I was typing along with every single line of code that appeared. And I still did not understand every chapter. But this was a much nicer experience and I’ve learned a ton. Of course you can give it a swing, even as a beginner, it’s free. But don’t be angry at the writer or anyone else, in case you won’t get everything right away. If you do though, please send me an email and tell me how you did it. Thanks in advance.
In the end I haven’t really read a good book for beginners. Also, reading on it’s own has a great disadvantage. It does not train your “muscle memory”. Like a pianist, your brain and your fingers need to get used to typing out programming syntax. With just reading you might glance over code examples, thinking you got it when you really didn’t, yadda yadda yadda. So if you got a good book, it makes more sense to read it on your computer, with an editor open. Which obviously I did not. Even though I had heard you should. …maybe one just has to live through that experience of total waste of time.

6. Learning HTML, CSS, JavaScript Round 2
(about 20 weeks: Nov 2017 – March 2018)
Easily my most favorite way of learning is: getting told what to do. And being evaluated whether you did it right. So my holy grail of learning is:
Interactive Tutorials.
Tadaaaaa! And my place to go is codecademy. I busted through the introduction to HTML and learn CSS tutorials and afterwards spent quite some time on introduction to JavaScript. In those tutorial webapps you have a split screen. With short topic explanations and small consecutive tasks on the left. On the right you have an editor where you write your code-solutions to those tasks. You run your code, it get’s tested and if it was correct, you get to the next section. What an experience. I could not believe that those things where out there. FOR FREE! Btw. I also heard good things about KhanAcademy and FreeCodeCamp. Very similar concept, I just haven’t tried them. Which is a good sign. Because coming back to tutorial-land for the same topics over and over, just to reassure yourself you haven’t missed any subtopics is just bad. You won’t remember all the available JavaScript-functions or all the little syntactical details on every single HTML-tag anyway. This is where one looks things up on:

  • Google
  • stackoverflow (incredible forum, which mostly is the first google search-result anyways)
  • MDN (by Mozilla)
  • W3School (tutorial / encyclopedia with “try-it-out-functionality”)

7. Learning from Podcasts
(almost every day)
Podcast were something I had underestimated a lot. If you get the right ones, they are helpful, educative and simply fun to listen to. Some of my favorites for your daily commute or while you’re cleaning the house are:

8. YouTube
(when ever there is time)
Learning material on YouTube is something I really like watching. But because it is so time consuming and sometimes difficult/impossible to code along. I watch them not too often. The two channels that stuck with me are:

9. Getting started with MachineLearning
(9 weeks: 01 Mar 18 – 16 Jul 18)
Not having a real project and thinking to myself: “Doesn’t everything of value nowadays involve data processing?” made me wanna dive into MachineLearning. Well say hello to all those worms escaping from this massive can I had just opened. Long story short. I followed the highly recommended free MOOC (Massive Open Online Course) by Andrew Ng on Coursera. Veeeery interesting. And faaaar beyond my capabilities to apply what I was learning to some real life problems. Nevertheless, I now have a decent overview on the field of machine learning. Which helps in case you want to wrangle some data using a more human friendly framework. Do you need it? In my opinion, only if you actually want to get into MachineLearning.

10. The Scary Commandline
(1 day: May 2018)
Depending on your system (Mac, Linux, Windows) it can be called Terminal, Shell or Console. It is always the same. You have an almost empty window with some directory (folder) on your computer written down in the top left corner. And you can type in the line behind that directory-name like in DOS times, if you’re young enough to remember that. When you hit Enter, the things you just have typed get executed. If this command is unknown to the program (shell, terminal, console) it just prints (writes in the next line) “command not found”. I wish someone would have told me that in the beginning. For weeks I was scared to type anything in the command line. To me if felt like I was carrying out brain surgery on the open head of my operating system and every wrongly typed command could probably lead to instant self destruction. While that is not the case and most developers do not have to become experts on the command line, carelessly copy-pasting install commands from stackoverflow should not be excuted either. Here is what I recommend: After finishing the HTML and CSS basic tutorials on something like codecademy, quickly work through the learn the command line course there. It doesn’t take very long but it gives you almost superpowers in the sense of how much more secure you’ll feel in the console.

11. GitHub basics
(1 day: May 2018)
In real life projects (in small and big companies) you have the situation that many people work on the same code base, while this very program they work on is running online. How is that even possible? With version control. What does that mean? There are simply different copies of the code available to the developers, called branches. If some new code has been written locally and it has passed all the tests it gets merged into the real application code on the master branch. This clever system is called git. Why should you care? Because there is an online service around that system called GitHub which makes version control possible to everyone, even for your own projects, so you can work on new features for your app, while another version runs fully functional on the web. GitHub also works as a repository for your projects. And since it is the go-to-platform for open source projects you can look at the the actual code of your favorite open source program. AND you can even participate if the maintainers allow open contribution. How cool is that. If I haven’t convinced you by now: GitHub shows a timeline, monitoring your activities. Every time you push (upload) something to some repository, you’ll get a green dot on your timeline. And recruiters apparently like to look at one’s repositories and timeline to see how much coding experience that person actually has. This seems to be a controversial approach for recruiting if you listen to developers on podcasts, but as long as this is still being done, why not starting early with GitHub. You will come across it at some point no matter what. Where to start? Again: codecademy. Learn Git. Also not very long and if I remember correctly you even set up an account. Double Thumbs Up.

12. Learning a backend language
(June 2018 – until today)
If you start coding in JavaScript, interacting with HTML and CSS, you tend to work on what is called the front-end or client side. Things the user behind the screen interacts with. This is extremely simplified and I recently listened to a podcast episode of Software Engineering Daily, where Malte Ubl from Google said: “effectively everyone at Google is a frontend engineer, right? Because there’s always a backend that you’re talking to…” As you see, this discussion could go very deep. Which I won’t go into. But if you want some computation being done outside the browser, on some machine (e.g. a server), you need a certain environment. A runtime. That translates your code (which in the end is just text) into machine code. And for quite a while that was not possible with JavaScript. So people looked at PHP or Python. I chose Python. It is a very cool language, looks different than most languages because it separates blocks of code not by wrapping it in curly braces but through line indentation. And the community around it is huuuuuge. Meaning that there is a lot of learning material available on the web. And there is a lot of extra code (libraries) written by others, which you can download, import and use in your projects. Nevertheless, there is Node.JS now. JavaScript in a car if you will. And that makes it possible to write JavaScript for the back-end. So if you even want to get into that server side, routing, data query, backendy stuff, with just learning JavaScript, you can still sit on both sides of the table.

13. Learning Rust (a low level language woooooooo)
(Sep 2018 – until today)
At some point I heard about this distinction between high level and low level languages. The latter is closer to the operating system. Which is why very efficient algorithms are written in C or C++ for example. Those are such low level language. An alternative and much younger language is Rust. So I read the Rust book. A tutorialish online documentation about the Rust programming language. Very interesting. Not particularly relevant for beginners. I’d even say if I had started with Rust, my shock about how difficult programming can be would probably have been even bigger than my reaction to Java. Rust is a topic for maybe another post on another day. Just hear that: With JavaScript or Python you can not write operating systems. At least not yet. With Rust you could, like you could with C or C++. Boom!

14. Courses & practice playgrounds
(Nov 2017 – today)
In case you have completed some tutorials, you understand the fundamentals of git and still don’t know what to build? Or your want to up your game, maybe practice in your lunch break? There are great courses to fill that gap. At the moment I am in the middle of Wes Bos’ JavaScript 30 course. 30 tasks, explained by him in high quality videos. An absolute treat. He also offers a very famous CSS-grid course which was done in cooperation with Mozilla, which is on my to-do-list. Both are free of charge and the best way to see if you like his style and maybe even purchasing one of his payed courses.
One of my favorite in-betweenies are quiz/puzzle/challenge sites. You just hop on to their site and try to figure out some programming problem. The ones I have tried and that I think are all fun are:

15. Staying up to date
(in between things)
I am from Germany and Twitter did not take off as much as in many other countries it seems. But if you want to get the daily news and topics and you do not have an account yet, get one. You don’t have to become all posty. But you will be surprised how much help, amazing blogs and tips are offered there. And of course jokes and gossip, but who doesn’t like that.
Other update resources which I haven’t really used yet would be reddit, HackerNews or HackerNoon.

16. Blogging
(2017 – today)
The best way to remember thing you have learned is to write it down. So my idea was to have this blog sort of as a diary. Writing down all the things I learn. But for almost an entire year I did not. Why? The answer is simple. I wanted it to be a certain, very ambitious way. And that was just always a bit too much for the time I had. I elaborate a bit more on that in my last post “Procrastination is caused by Perfectionism”. But blogging or even just writing things down for yourself is great. It will help you sorting your thought. And if you forget things you have already learned you can go back to your scribbles to refresh your memory. Once you put your findings out there, on the web, you might even help others on their journey. Which is what I hope to achieve as well.

Coding is the best hobby I have picked up in years. It makes me feel empowered. You can do so many things with it and endlessly grow in the field. So if you just want to get started with something? Here are my absolute highlight tips.

To set you up properly, not wasting any time fumbling around, immediately start with interactive tutorials on either codecademy or FreeCodeCamp or KhanAcademy. I suggest the following order:

  • HTML Basics
  • CSS Basics
  • Learn the CommandLine
  • Learn about git
  • JavaScript Basics

Concurrent to the tutorial (on your commutes, while in the gym or while cleaning the house):

Getting more practice:

Thing I haven’t touched on but might be worth looking at:

I think that is enough to start with. Once you have started you will ask your own questions anyway and look for the topics you want to dive in deeper, finding your own favorite resources. Hopefully this was any help to you and I would look forward to getting your feedback. If you like you can send me an email or get in touch with me on twitter. Meanwhile enjoy coding and let the world know about your experience.



how to become a programmer

This is my story about how I am becoming a programmer. And it is just at the very beginning. If you are only interested in resources – stop reading right here. Instead take a look at the resource-section. There I am posting stuff that helped me so far and will help you getting started as a developer.

For you, who is apparently still reading, let me briefly explain what is going on in this blog. I understand it as a diary-ish documentation of my journey to the center of programming. Mainly so I keep track of my progress. Secondary to spread useful, interesting, hopefully entertaining mush along the way.

This is how it went down:

On 23 July 2017 I was finally too sick of that feeling being left behind by this world of technology we are living in. Inside my head, a tiny little voice SCREAMED “I want to become a programmer NOW!”

So I did what everyone does that wants the quick and easy way out. I downloaded an app on my phone. A cute little question-answer gamified learning-app for JAVA. It felt awesome! and unfortunately also very useless. Once I had completed all chapters and thought I was half way there I installed and opened a big ass SDK (Software Development Kit). What happened next nothing less than I a minor panic attack. This was exactly how I felt all along. Like an idiot and that I won’t stand a chance to ever get a grasp of this stuff.

// little side note from the present: This has not been proven otherwise, yet. But I feel very confident I am getting somewhere, as you will find out in later posts.

A first introductory shouldn’t be too long but I want at least end on slightly higher and uplifting note.

Of course the job wasn’t done by rushing through an app, millennial-style. Also it was maybe not a particular fortunate choice to start with JAVA (which is great and versatile but not very beginner friendly). I just did not know where to start. The good news is: there is guidance out there. And so sooo SOOOO much stuff that is absolutely awesome to learn about programming. And the best part. A vast amount is totally for free (people luckily brag about their knowledge and share it more than is good for them). Programming can be self-taught for the most part. AND it is extremely fun to make progress with. I might still be in the rather shallow part of a learning curve. BUT for someone who thought that there is like THE ONE major programming language everyone uses nowadays I have come a long way.

After my little stumble in the beginning, I’ve mainly looked at webDev (Web Development) stuff with JavaScript. Which is, as everyone knows but me when I started, not the same as JAVA. I’ve looked at HTML and CSS, nothing on the web can be done without those two fellas (BTW never EVER say you program in those two. They’re markup-languages and people look weird at you if you call them programming languages). And of course I read a lot about certain concepts, like client-server communication, APIs (Application Programming Interface), listen to podcast and on and on and on. It is very rewarding, i.promise.

To sum up: You are an advanced programmer? This might not be your blog, unless you like my writing. Then please let me know. Who doesn’t feed of flatterment. If not, well I guess you won’t have read this far anyway. Are you new to programming? You actually might get some good information to start with. And I aim to keep developing that part.

Final secret: The actual purpose of this blog is very egoistic. While learning loads of new stuff, I tend to forget things that I already learned. So writing it down seems to be most efficient for memorization. Here comes my first life-advice: write things down! Thank me later.

That is it for today. Get on coding, have fun and stay connected.


It’s all about being connected

Bangkok electric wires

photo: electric wires in Bangkok, taken by myself 2016