
I’ve written 2 blog posts, never edited a YouTube video, don’t have a large social media following. But I do have one thing going for me, I can create just about any software tool you can imagine.  Being a developer is still sort of a super power even in 2023 with the rise of no-code, automation and AI. However, it’s not the most important superpower. That is reserved for great marketers, they’re like superheros of the digital age. Let me elaborate.

As a developer, you can create anything. I’m a builder at my core so I love dreaming up an idea and piece by piece taking idea to reality. However, in a real sense, the only reason to build things is for people to use. So in an age where anything can be built with software, what’s the missing ingredient? It’s people. People are the scarce resource of the internet. This is where marketers come in.

Marketers are people engineers. They understand how people work and can tell a compelling story to illustrate the value of a great product. This does require having an actually great product — which is easier said than done. Marketers know where people go. They know how to create value-adds where potential customers, readers or subscribers are. Not slimy, click-bait schemes, actual value adding content, tools, etc. They go to the people and help get your tool in front of the _people_ who will use it. This takes many forms, but it all comes back to people, the scarce resource of the internet.

A lot of people get a bad taste in their mouth when the word ‘marketing’ is mentioned. I think this is because people often confuse marketing with sales. Great marketers aren’t sales people, they’re story tellers and value-adders. Marketers know how to take a great product and get it in front of real humans who will benefit from using, reading or otherwise consuming the product. This is fundamentally different than sales, which is more of a persuasive process. In my mind, great marketers simply know how to identify a great product that solves a real problem and then tell that story to people who will benefit.

Additionally, marketing in 2023 is not what most people would think of as marketing. Imagine meeting someone on the street who introduced themselves as a marketer. I used to picture a Don Draper like character, a lofty executive in a glass corner office or an untouchable super personality. In reality, marketers are just people who know how to tell a story on YouTube, craft a great Instagram post or write a great article that will improve a reader’s life. Marketers aren’t sales people, they’re not lofty executives, rather they’re simply great story tellers who bring awareness to great products.

I know I can develop a good product. However, I’m not sure I can build the _right_ product or harder yet, get anyone to use it. That’s why I’m learning marketing. If building is all about the people using it, then you should start there. Start by talking to people, adding value where ever you can. Then, when the time is right, build a great product for _people._ I’ve tried to do the reverse, and I ended up with a tool that I thought was great, but no one knew about.

I’m not giving up, rather focusing on putting the horse before the carriage. Ultimately I want to build things that improve people’s lives. Weather that be a kitchen table, software tool or side-business. Building things brings me great joy, but I want people to enjoy and use the things I use. That’s why I’m learning marketing.

Why I'm Learning Marketing as a Developer


There will come a time in every Rails developer’s journey when the MVC and ‘fat controller, skinny model’ approach just ins’t cutting it. It could be a complex billing service, an object that touches multiple models or a complex form. The good news is that when these situations arise, we have more tools at our disposal as Rails engineers. One of those tools is form objects. We can use form objects to help simplify complex forms using ‘Rails-y’ patterns and the ActiveModel::Model module. Lets take a look!

At their core, form objects are just classes. They’re built in such a way that they feel like active record objects but can be more flexible to suit your needs. Let’s imagine a scenario together. You are building a CRM for a plumbing business. There is a Customer model, a Job model, a Message model and a Payment model. In order to submit feedback on a job, a customer must have completed payment for a job. The customers/messages#new controller action will be responsible for displaying a form to allow a customer to submit a message to the company, again assuming that they have completed payment for a job. Then the customers/messages#create action will be responsible for running validations and then creating the Message record if the validations passed. Let’s take a look at how we may build this without a form object.

~~~ruby
class Customers::Messages < ApplicationController
  before_action :authenticate_user!
  before_action :set_customer

  def new
    @message = Message.new
  end

  def create
    # Check to see if the customer has a completed payment for a job
    unless @customer.payments.where(status: :completed).exists?
      @message.errors.add :base, "You must have a completed payment to send a message"
      render :new, status: :unprocessable_entity
    end

    if @message.save
      redirect_to customer_message_path(@customer, @message)
    else
      render :new, status: :unprocessable_entity
    end
  end

  def show
    # ...
  end

  private

  def set_customer
    # ...
  end
end
~~~

This will do just fine, but there is a better way! We can create a form object for a new message that will take care of this validation for us. Lets take a peek at that new form object class.

~~~ruby
class NewMessageForm
  include ActiveModel::Model

  attr_reader :message, :customer

  # Use built-in Rails validation techniques to do the validation
  validates :text, presence: true
  validate :customer_has_completed_payment

  def initialize(text:, customer:)
    @text = text
    @customer = customer
  end

  def save
    valid? && Message.create(text:)
  end

  private

  def customer_has_completed_payment
    # Here is where we perform the complex validation

    unless customer.payments.where(status: :completed).exists?
      errors.add :base, "You must have a completed payment to send a message"
    end
  end
end
~~~

Notice how we can take advantage of the Rails validate method to perform that more complex validation in a Rails-y way. Now, our more advanced form object encapsulates the logic required to validate and save a new message form to the database. Now, let’s update the controller to use this new form object.

~~~ruby
class Customers::Messages < ApplicationController
  before_action :authenticate_user!
  before_action :set_customer

  def new
    @message = Message.new
  end

  def create
    # Notice how much cleaner this is in the controller. Much easier to follow.
    @form = MessageForm.from_params message_params, customer: @customer

    if @form.save
      redirect_to customer_message_path(@customer, @message)
    else
      render :new, status: :unprocessable_entity
    end
  end

  def show
    # ...
  end

  private

  def message_params
    params.require(:message).permit(:text)
  end

  def set_customer
    # ...
  end
end
~~~

We no longer have that ugly conditional at the top of our #create action performing some low level checks. We can treat the form object like we would a regular ActiveRecord backed model. As you progress in Rails, you’ll find that #create actions in controllers often times take the shape of our action here. As your application grows, business logic should be pushed into other objects to allow for greater readability, re-usability, etc.

You’ll notice a new method .from_params being called on the form object. This is a class method that is responsible for creating a new form object from the request’s parameters. Check it out below.

~~~ruby
class NewMessageForm
  # ...

  def self.to_params(params, customer:)
    # This method converts request params to a valid form object

    new(
      text: params[:text],
      customer:
    )
  end

  # ...
end
~~~

This just allows for even more re-usability because the form object itself knows how to instantiate itself from standard Message model params. You can now use this in another controller without writing any more code to handle new message form logic!

You can take this even further if your use-case is more real-world. I’ll detail that in a future article soon. I’m also hoping to create a demo application and repo to show off these advanced Rails patterns. Thanks for reading! Subscribe with your email if you’d like to see more advanced Rails tips like this.



Articles

Subscribe

Why I'm Learning Marketing as a Developer

Advanced Form Objects in Rails