A marketing guy's guide to Getting Technical(i.mhj.tc)
i.mhj.tc
A marketing guy's guide to Getting Technical
http://i.mhj.tc/gettechie
18 comments
It's not about the tools - they're necessary to have the experience, but not sufficient. To me, it's about the intellectual approach of hacking.
I agree. I've been in the software industry for over two decades and I can tell you that untold damage has been done by marketers who have a half-baked idea of the technical details. For better or worse, marketers produce and control much of the language used to describe products. Doing this badly sows mistrust and sullies technical terms, making it harder for the technical side to communicate.
it's about the intellectual approach of hacking.
This bears emphasizing. When anyone is dealing with a concept outside of their core discipline, they need to QA their conceptualization. Any analogies you discover will be flawed at some level. You are probably not going to get it right on the first iteration. Getting it right probably means some genuine learning on your part.
I agree. I've been in the software industry for over two decades and I can tell you that untold damage has been done by marketers who have a half-baked idea of the technical details. For better or worse, marketers produce and control much of the language used to describe products. Doing this badly sows mistrust and sullies technical terms, making it harder for the technical side to communicate.
it's about the intellectual approach of hacking.
This bears emphasizing. When anyone is dealing with a concept outside of their core discipline, they need to QA their conceptualization. Any analogies you discover will be flawed at some level. You are probably not going to get it right on the first iteration. Getting it right probably means some genuine learning on your part.
I completely agree. Necessary, not sufficient. Covering the specifics, which are just the tools and a basic foundation, is empowering and motivating IMO. A big part of learning basics like this is just learning the vocabulary for describing the larger challenge you want to tackle. Knowing that you have the tools and the basics is necessary for learning more, and ultimately, getting to the point of building, polishing and delivering.
If you work in a small team, especially a startup, knowing what’s going on and how your product works is valuable also to a non-technical business co-founder
Couldn't agree more! (especially for product people)
Can you give more specific details about how it helps you/the team? (no sarcasm here, I'm genuinely interested to understand this form the marketers' perspective)
Couldn't agree more! (especially for product people)
Can you give more specific details about how it helps you/the team? (no sarcasm here, I'm genuinely interested to understand this form the marketers' perspective)
Thanks. One specific example could be resource sharing. We use Github for code, but also for issue tracking (which brings with it discussion threads) so using Github properly even if not making code commits is valuable so you stay on top of issues and questions and can contribute. And in my case, I know I can make small fixes myself, so I want to have the infrastructure in place and know how to use it.
If you are working remotely, you want to be able to see the latest development version and run it locally, not just the latest alpha push. In the real gritty details, I just had to update Maven on my local machine and fix a Github conflict, and had to ask for help figuring out where the missing components were and how to fix the error messages. If someone has to take an hour helping me get this done, it is unnecessary overhead. I still almost broke things in vim though, but know what I have to learn.
More generally, a technical product understanding just helps in communication. If the tech lead makes the decision to refactor the code, which leads to delays affecting the business, it's good to know why.
If you are working remotely, you want to be able to see the latest development version and run it locally, not just the latest alpha push. In the real gritty details, I just had to update Maven on my local machine and fix a Github conflict, and had to ask for help figuring out where the missing components were and how to fix the error messages. If someone has to take an hour helping me get this done, it is unnecessary overhead. I still almost broke things in vim though, but know what I have to learn.
More generally, a technical product understanding just helps in communication. If the tech lead makes the decision to refactor the code, which leads to delays affecting the business, it's good to know why.
> More generally, a technical product understanding just helps in communication. If the tech lead makes the decision to refactor the code, which leads to delays affecting the business, it's good to know why.
That's great! I'm interested mainly in these kind of benefits. Besides communication, how does it help your relationship with customers/team/partners?
That's great! I'm interested mainly in these kind of benefits. Besides communication, how does it help your relationship with customers/team/partners?
Can you give more specific details about how it helps you/the team?
The marketer needs to have enough of an idea of how the product works to be able to talk about it intelligently. "Enough of an idea," means one needs to know what the relevant parts are, and how they interact.
Imagine you are a contractor putting in a kitchen for someone, and they sometimes refer to the sink of the island and the sink on the rear counter as if they were the same thing. I wouldn't know which one they're talking about and it would drive me mad. Marketers make mistakes of this magnitude all the time.
The marketer needs to have enough of an idea of how the product works to be able to talk about it intelligently. "Enough of an idea," means one needs to know what the relevant parts are, and how they interact.
Imagine you are a contractor putting in a kitchen for someone, and they sometimes refer to the sink of the island and the sink on the rear counter as if they were the same thing. I wouldn't know which one they're talking about and it would drive me mad. Marketers make mistakes of this magnitude all the time.
I work in business development at tech company where our core product is an API. Learning the basics of programming helps me find the right customers for our product, and then support them better. http://janineyoong.com/post/23665444733/learning-to-code-at-...
Just one thing that obviously jumped out, the link to the MVC explanation is not great.
http://www.codinghorror.com/blog/2008/05/understanding-model...
This dude says MVC == HTML, CSS, 'the browser', respectively. Not sure many would agree with that assessment. If anything those three could, I suppose, be viewed as a separation of concerns, calling it MVC however, just seems muddy.
For example the way I see the pattern in terms of web apps (and MVC is not a domain specific pattern in any respect either):
- model should be largely in code and data and contain the business logic, not HTML.
- view is a mixture of HTML/CSS
- control is a mixture of the browser engine's logic and client side javascript.
Also Github and .NET don't seem to fit well together based on the types of communities. ;) That's not to say they can't in the future, just speaking historically.
http://www.codinghorror.com/blog/2008/05/understanding-model...
This dude says MVC == HTML, CSS, 'the browser', respectively. Not sure many would agree with that assessment. If anything those three could, I suppose, be viewed as a separation of concerns, calling it MVC however, just seems muddy.
For example the way I see the pattern in terms of web apps (and MVC is not a domain specific pattern in any respect either):
- model should be largely in code and data and contain the business logic, not HTML.
- view is a mixture of HTML/CSS
- control is a mixture of the browser engine's logic and client side javascript.
Also Github and .NET don't seem to fit well together based on the types of communities. ;) That's not to say they can't in the future, just speaking historically.
Thanks. This is partly why I made the point of there being good comments to that post - I can see there are plenty of differing opinions on this, and I'm can't say what is right. But, for a newbie to thinking about program structure (well, at least for me) presenting that with clear borders is helpful. But I think you're right, calling it MVC is not helpful. What should the HTML/CSS/browser bucketing be called instead?
Theoretically, it's not a bad point of view, but for a newbie, it's not how the concept "MVC" is normally used. I would suggest linking to something like this: http://guides.rubyonrails.org/getting_started.html#the-mvc-a... - Now, Rails isn't the only way to do MVC, but it's more or less the de-facto standard, so it's good for understanding the basic concepts.
I don't think it makes sense to consider HTML-CSS-JS as a triad on par with MVC anyway. CSS and HTML are very intimately related, so I think it makes most sense to consider them two parts of one technology. JS is more separated and generally takes different skills than HTML/CSS.
I don't think it makes sense to consider HTML-CSS-JS as a triad on par with MVC anyway. CSS and HTML are very intimately related, so I think it makes most sense to consider them two parts of one technology. JS is more separated and generally takes different skills than HTML/CSS.
Great, thanks, this is now addressed in an edit in the post. Also good point on making a separation based on skills.
Pleasure. As for your question, hmm not sure, but I suspect SoC (Separation of Concerns), fits the closest.
http://en.wikipedia.org/wiki/Separation_of_concerns
http://en.wikipedia.org/wiki/Separation_of_concerns
I don't see why you need to learn vim. Just open your files with your preferred editor from the command line, as in Michael Hartl's Ruby on Rails tutorial. It's a google away to set up 'subl' to open a file in sublime text 2, for example.
I think the larger idea of knowing the surrounding tools and resources is crucial and can be glossed over (for example, not once has a professor at my university mentioned StackOverflow). Great idea making this post mikk0j.
I think the larger idea of knowing the surrounding tools and resources is crucial and can be glossed over (for example, not once has a professor at my university mentioned StackOverflow). Great idea making this post mikk0j.
Thanks! And you're right about the text editor. I should do that for myself too. I guess vim is one of those things that you keep running into, and unless you never figure it out, it will remain a mystery (and if you accidentally do get it, you can do damage - I have!).
And that's a fascinating point about your professor not mentioning StackOverflow. Would be great to hear about what 'unofficial' or community-based resources do get mentioned in 'official' education.
And that's a fascinating point about your professor not mentioning StackOverflow. Would be great to hear about what 'unofficial' or community-based resources do get mentioned in 'official' education.
Hah, I know what you mean about it being a mystery. Honestly, whenever I accidentally open vim I end up closing the terminal window to get out of it. I suppose that means I should at least learn how to exit it and such.
Am I the only one annoyed by tutorials in video form? I can't hear myself think, I can't set myself the pace, you can convey up only so many informations with sound and image... I like real lectures in video, but it's not a really good format for quick tutorials.
As a techie, what I would love is "A Technical Guy's Guide to Marketing/Sales" that basically talks about the various concept and jargon a techie should know to run a business.
Once a business founder has hacked his way from an idea to a polished version of something, he can be much better at his job.