Job Seekers Should Have Some Linked In Activity

If you are looking for a job, and have a Linked In account, it helps to have some activity in your account.

You don’t need to be a Linked-in influencer, but if there is no activity (or the last thing is very old), then I would assume that person doesn’t even use Linked In. When I’m looking for developers, I skip those profiles because it doesn’t look to me like they want to be contacted. If you are open to being contacted, create some activity—all you need is a few comments and reposts.

If you are looking for something to post, just post that you are looking for a job and what specifically you are looking for. Be specific. Build a Job Statement, and then use that.

I suspect that Linked-in will put you higher in search results as well.

    Moore’s Law of Football

    A few weeks ago, I wrote about what computing did to baseball, which was that it had doubled the number of stats they report every 18 months.

    Right now, I am watching the Jets on Monday Night Football. It’s been a while since I tuned into a game live because I don’t live in NYC any more, so the Jets are hard to watch.

    The thing that stands out to me is that there don’t seem to be any new stats. Maybe football really is just yards and points.

    More likely is that there have advances in stats that help scouts, but the announcers have concluded that they are boring. They are right.

    Write While True Episode 34: Word of the Day

    What we’re trying to do is we’re trying to learn how to recall fit words when we need them in our writing. To get better at that, we need to be exposed to more interesting words and to practice using them. Imagine situations where they would be perfect. Making it memorable and ridiculous might help you remember the word when you need it.

    Transcript

    Pull Requests for One

    I work alone on my programming projects, but I still make pull requests. I also review my PRs. It feels silly hitting the Approve button in BitBucket, and BitBucket knows that. It keeps warning me that my PR doesn’t have any external reviewers.

    In 2003, the first year of this blog, I wrote about using Source Control for One, where I agreed with Eric Sink that source control was useful when working alone. It’s hard to think that there was a time when that would be non-obvious advice, but it wasn’t.

    Today, in 2023, I think making PRs when working alone is probably common. I think that reviewing them isn’t. I’m not sure if I can convince you, but the reason I do it is that I keep finding problems. Also, it keeps me honest and makes sure that I keep Constructing PRs to Make Reviewing Easy.

    PlantUML is Byzantine, but I’m OK With That

    When you first see PlantUML for simple diagrams, it looks like just a simple data format. It is not. As you go from diagram type to diagram type, you see lots of alternate syntaxes. For example, any JSON object is a valid PlantUML program. It generates a visualization of the JSON.

    More than that, there are mini-languages embedded in some formats. Creole, a simple formatting language, can be used to provide the content for a box in your diagram.

    PlantUML also offers a powerful preprocessor with variables, functions, and procedures, loops, conditionals, etc and some diagram types (e.g. C4) are built just with these abstractions.

    It seems that whenever the maintainers want to add new features, they seem to lean on more syntax and embedded parsers. The result is both that the onramp can be very gentle to non-programmers because it can look very natural. Here’s a simple sequence diagram:

    @startuml
    actor User
    User -> A: DoWork
    A -> A: Internal call
    A -> B: << createRequest >>
    A <-- B: RequestCreated
    User <-- A: Done
    @enduml
    The sequence diagram that goes with the code next to it. It has a User and two objects (A and B) and shows some messages between them

    That’s great! If that’s all you want from your sequence diagrams, PlantUML syntax is very nice. I don’t even think I need to explain that syntax. But, as soon as you want more control or extra elements, it gets complicated quickly.

    My sequence diagrams all use lifetime bars and show creation and deletion. There is a short-hand for all of that, and here’s an example from the reference guide.

    @startuml
    alice -> bob ++ : hello
    bob -> bob ++ : self call
    bob -> bib ++  #005500 : hello
    bob -> george ** : create
    return done
    return rc
    bob -> george !! : delete
    return success
    @enduml
    A sequence diagram with activation bars on the lifelines.

    It’s still manageable. But, it goes deeper and deeper. It’s hard for me to imagine that there’s a sequence diagram I’d want, but couldn’t get. But, there’s a lot of random, seemingly unrelated stuff I’d need to learn to get it.

    I’m ok with that, because I want diagrams-as-code more than I want simple code. And I know that most of the time, the code isn’t that bad.

    When to Code a Diagram

    I’ve been porting all of my draw.io diagrams in Confluence to PlantUML. Both tools meet my minimum requirements for diagrams in documentation.

    1. The diagram must be editable inline in the document
    2. The diagram elements must be able to be links
    3. The diagram doesn’t need to look perfect, but it can’t be wrong.

    It’s come down to Draw.io and PlantUML, which are very different from each other. Draw.io is a typical point-and-click drawing program. It’s web-based, and about as good as that can be. PlantUML is a programming language for creating diagrams. The editing experience is a text editor side-by-side with the rendered diagram. Both Draw.io and PlantUML can do my minimum list, but there are some things that are making me favor PlantUML.

    1. I’m documenting, not designing. I’m not trying to figure out the system I am documenting—I am just trying to communicate it quickly at the top of a document that goes into details. If I were still designing, I probably would want to draw, but honestly, it’d be on paper or with freeform drawing tools.
    2. I accept the default layout engine. In PlantUML, it’s best if you let the layout engine do it’s thing. I’m still learning how to influence it, but try not to worry about it too much.
    3. I’m comfortable with programming languages. PlantUML is a weird programming language with syntax affordances for diagramming and other embedded mini-languages. Simple diagrams are simple, but I find that I need the more advanced features for all of my diagrams.
    4. I like the idea of version control and diffing. It’s text, and line-oriented, so it works well with diffing.
    5. I could generate this. I love to generate code and so learning this will ultimately lead to me generating it some circumstances.
    6. I can edit quickly. If I want to fix a typo, I don’t have to click-click-click to get to the part where I can type. The text editor is very good. Also, I can easily copy and paste from other diagrams and samples.
    7. I can make my own library. Drawing tools let you make template shapes, but PlantUML is a programming language (with conditionals, loops, math, etc). The tools it has for abstraction are way beyond what drawing tools typically do.

    I might just be repeating what the diagrams-as-code people have been saying all this time, but until PlantUML, I hadn’t used anything that was good enough to get these benefits (because they didn’t meet the minimum).

    PlantUML for Confluence

    When I wrote C4 Context Diagrams in GitHub READMEs to show how to use GitHub’s support for Mermaid diagrams, I was disappointed with the output. One of the nice things about the Diagrams-as-Code movement was that the default layout should be good enough. I found that even simple diagrams looked bad by default, and I had to spend too much time to make them look good. To be fair, I think C4 support is still in beta.

    I’m mostly interested in C4 diagrams in my documents, and for that, Mermaid supports PlantUML syntax. I wanted to try PlantUML, but I assumed that the rendering would be similar to Mermaid. I was wrong.

    My documentation is in GitHub for open-source projects, but for private projects, I use Confluence. I found the PlantUML for Confluence plugin from Stratus and ported one of my system context diagrams. It took a few minutes and 13 lines of code—one for each component and one for each relationship. The default layout was fine.

    The rest of my diagrams are more complex. I’ll be porting them over the next few days.

    Post #500

    I started this blog in 2003. This is a milestone post—Post #500. I have been writing more frequently since 2021. Before 2020, I had less than 200 posts. Well before that, this blog was useful to me.

    • My posts about developing for iOS in 2008 were found by an editor at Manning and I wrote a book for them. This helped me make the transition to full time iOS development.
    • My posts about extending Fogbugz and Citydesk were part of my application to Fogcreek/Trello — I can’t say it “got” me the job, but I’m sure helped me get an interview.
    • I’ve been invited to speak at conferences, be a guest on podcasts, and write for Smashing based on people finding my site. It’s not a lot, but raises my profile just a bit.
    • I don’t monetize this site directly, but it’s pretty much the only way I market myself.

    I didn’t set out to do any of that. I write on this blog because it’s fun and I want to be a better writer. But, even this blog—a relatively obscure one in a space crowded by very similar voices—has made a significant impact on my career.

    Write While True Episode 33: Collect Sentences

    The idea of collecting quotes is not something new. I think that’s the way most people think of note taking in general. There’s even a style of journal some people keep called a Commonplace book, which builds on this idea. In a Commonplace book, you are mostly collecting the thoughts of others. You might also put in your own reaction to those—your thoughts on those thoughts—but the focus is on the collecting.

    I want to recommend a spin on this idea.

    Transcript