• Skip to main content
  • Skip to footer

InRhythm

Your partners in accelerated digital transformation

  • Who We Are
  • Our Work
  • Our Culture
  • Events
  • Testimonials
  • Blog
  • Contact Us

Software Engineering

Jul 13 2015

Who runs the world? Code, Code: What Development Can Teach Us About Creativity and Being Prepared for the Future

I recently read a LinkedIn post by Dan Robinson on the negative effects of social media and sharing designs and it has caused me to wonder if designers can learn more from developers than the value of coding as a skill. Maybe us designers can learn a little something about what it means to have a strong community to draw inspiration from. In his post, Robinson explores issues of self esteem and what inspiration, if any, designers can and should take from others. He highlights a common concern that we may be ‘comparing ourselves to death’ not only as individual human beings with social media and how we compare to others, but also as UX and visual designers because of constant exposure to what others are doing. Harold Bloom was an early analyst of the role of influence and peers on creativity, including his 1973 work called ‘The Anxiety of Influence’, and how the issues of feeling confident in designs will always plague designers, who often are self reflexive in their outlook to begin with.

Being a designer isn’t just about finding solutions – it’s about critiquing a state to improve it for the future, and as a result, criticism is often the default for many of us. Social media, and communities of practice, have value in learning the craft of design, and designer communities like Behance andDribbble help as a place to explore and share concepts and drafts. But, there is a downside to all of this sharing – Dribbble’s concept of a ‘shot’ often leads to designs which only look beautiful in a small, 400×300 pixels canvas. Good designers can become wracked with self consciousness if their design doesn’t look anywhere near as perfect as a final product on Dribbble. Ironically enough, the less glamorous design could be the right solution for a client and their customers even if it doesn’t win any design awards for Best Use of Flat Design on Buttons, or get voted up as noteworthy.  When we do see the perfect final version, we don’t get a feel for all the struggles which occurred behind the scenes. We don’t see the designs which were thrown out, and more disturbingly, few requirements or constraints (business or technical) are stated in a case study that accompanies that final image. Often there’s no case study at all – just an image, and people may see these final designs as solutions worth emulating. When designing more complex, enterprise transactional applications, is a simple, elegant, stylized shot found on Dribbble really the best source of inspiration? Should redesigns that focus on polish and the continual sharing of final products really be leading designers to late night bouts of existential anxiety?

How do other creative professions in technology – particularly, developers – deal with anxiety from creativity and comparing their work to others? What can designers learn from developers on how to feel confident with the sharing of their work? From the outside, developer communities appear to be less anxious and ultimately better prepared for the changes of being a professional knowledge worker due to a number of key practices about creativity which have developed as accepted standards. It’s not that designers and other professions don’t have the equivalent practices, but there may be a focus more on processes and practices in the building, and comfort in the ‘draft’ state rather than a focus on a final, finished, polished product. Some of the best developer practices when it comes to creativity include (in no particular order):

  • Pair programming as a practice: A core part of Agile development is developers pairing together to solve a problem. It’s not always a more experienced dev with a beginner – there’s an active sense of people who can be equally experienced working together through the best way to code. You can have two developers well versed in Ruby, who differ in how they construct code. There are often multiple ways to frame any solution, with no clear obvious direction. With pairing, you work through the options, put together multiple minds and find that best solution as you evaluate the options in real time. I’ve paired with designers before, and there is an active movement towards Pair Design as an initiative, but as a rule, it’s rare as an established, encouraged practice. There’s no reason why it should be, especially if multiple designers are working at the same company to help achieve consistent brand standards across products with multiple UIs. Smart companies have an active internal designer community, but in the education of designers, we rarely talk about pairing with individual designers as a practice – it’s usually one designer, and one product. Having an extra mind and set of eyes can help you see things that were missed the first time. I’ve worked with developers who sit with each other – different pairs on different days, and it’s what works for many of them.  Contrast that with the cliche of the Genius Designer silently sitting in the corner working away in his black beret. Perhaps pair designing might bring some of those solitary folks out of their shell and they will recognize the value of learning by collaboration. Maybe this will diminish the Genius Designer myth, too.
  • Communities of practice expressed in products, not just discussion: Developers have code repositories where hacking, experimentation and continual iteration are welcomed in addition to the usual forums for communication. Their tools are built out, languages created, and snippets shared on GitHub or other sites where the purpose is about sharing as much as an active finished product. Granted, it’s easier to share a code snippet than the outputs of a design especially concerning NDAs, and again, designers actively work to share their equivalent tool libraries, templates and pattern language libraries. With developers there’s a narrative that is unconsciously spoken – if you don’t like something and want to fix it, then just fork it, and make it your own. Customize it, hack it, tweak it, build it. We’re starting to see that with designers and developers building third party tools to work with Sketch and other applications, effectively building an ecosystem around the act of creating.  The sheer volume of activity on Github alone indicates that developers have beat designers to the punch, embracing the ‘building is part of being a community’ mission. Creativity for developers is building – constantly, and encouraging others to build off what they’ve done. Any hackathon is an expression of creativity and it can be astounding to watch that creativity happen. When we say ‘creative’, how often do we default to a painting, novel or dance performance? Perhaps we can see hackathons as another kind of performance where the code and collaboration are a dance that can be just as beautiful to watch.
  • Constant evolution of languages: This is a touchy subject, as the amount of coding languages and frameworks is exploding, and at a certain point there may be too many of them for any one developer to keep up with. Still, the amount of active development of new languages demonstrates how developers are constantly pushing the boundaries of what they can do with code, and exploring new ways to do it. Everything we once could do in Flash and Flex is now being replicated with CSS3. Our languages will continue to multiply as our interactive experiences online evolve, and as the devices and ways to experience a product continue to proliferate. As a career in development, it can be exhausting to constantly learn new languages, but as a form of art and creation, it shows people creating. Photoshop was a standard for so many years, and designers are only now in the last couple of years successfully evolving their languages and tools to meet the needs of these more complex and sophisticated products.  In creating new languages, the practice is less about comparing yourself to others’ output than creating something new for the sake of trying to solve a problem.
  • A commitment to continuous learning: As more languages, tools, and standards evolve in how we build products, the only constant in responding to change is adaptation and a commitment to learning. Continuous integration isn’t just about checking in your code – it’s about how we learn and keep learning, keeping our eyes open for what to learn, building upon your existing knowledge and seeing where the past and present apply to the future. Everyone – designers, developers, product, sales and more – has to commit to constant openness to learning and evolving one’s skills. But with development, that learning is embraced at a hyper accelerated rate. You may not need to be an expert in everything, but you need to have an awareness of what matters in technology, and for some concepts, at least a recognition that you have a gap which learning can address, and if you need to know about something quickly, the best source of learning is to start mastering it. Thanks to the always-in-flux nature of Web and development languages and practices, you always have to be actively learning – and there’s a potential for developers to be doing so online quickly.  It’s no surprise that there are more varied ways of learning development and computer science outside of traditional education – the rise of online education points to evolving how we learn, and that evolution speaks to how development addresses creativity, too. No surprise – the rise of the Maker movement has a strong tech focus at its core, and the message of the movement is a positive one. Anyone can be a Maker no matter their education or skills, as long as they’re willing to try creating.

No matter what the medium, creative people will always be strivers, dreamers, the people who crave more, who ask why – and often why not. No matter what the medium (paper and pen, keyboard, paintbrush, or whatever comes next in the future) striving is one of the passions which drives us to improve our craft and seek out new ways to design or develop the products and services that change lives.  The trick for creativity is to remember it’s not a race to compete with the Jones’s and the Dribbbles – it’s to start embracing your inner creative spirit and hacking for the sake of hacking.

Written by inrhythmAdmin · Categorized: Design UX/UI, Software Engineering · Tagged: community, education, engineering, language, pair programming, ux

Jul 06 2015

Web Assembly – Addressing Javascript’s Fatal Flaw

Javascript is a necessary evil. Well, not exactly, but this is a belief held by some software engineers in various circles. The claims vary, but they attack the same basic underpinnings of the language:

As an interpreted, compiled-at-runtime, dynamic language, Javascript lacks even the ‘ability’ to execute operations at a speed that is commensurate with the machine and browser that is running it’s app.

True – it is not an assembly language. It was not intended as such. Nor did its origins intend it to be compiled to an intermediary language such as Java bytecode or .Net MSIL. That being said, it is the “Assembly Language for the Web”.

Optimization of Javascript is nothing new. There have been, and will continue to be, great strides made in things like module loading, compression, etc. However, none of these address performance at its core.

Enter ‘Web Assembly’ — the new binary format for the web. It is a charge led by Google, Microsoft, Mozilla and other key influencers. The binary format is in the form of an abstract syntax tree, and at first it will be a compilation target for high-performance application facets to be written in C and C++. The longer-term vision appears to include support for other languages.

Web Assembly will not replace Javascript. Instead, it will expand the application environment in which today’s Javascript-based apps run, and the possibilities are far reaching.

Written by Wes Reid

Written by inrhythmAdmin · Categorized: Product Development, Software Engineering · Tagged: JavaScript, web assembly

Jun 01 2015

Diving Into Template Strings with ES6

With the exciting beta release of ECMAScript 6, we thought it would be fun to play with one of its boasted features and provide a little tutorial. Template strings are strings that allow for embedded expressions.

With the exciting beta release of ECMAScript 6, we thought it would be fun to play with one of its boasted features and provide a little tutorial. Template strings are strings that allow for embedded expressions.

The Template Strings feature brings a lot of goodies to JavaScript strings and also helps us to eliminate extra libraries. It is supported by Chrome 41+, IE Tech Preview, Firefoz 35+ and also io.js. Most of the major ES6 transpilers also support this feature letting us start to use it in production immediately.

For template strings, we use the back-tick (` `) character instead of the regular single or double quotes.

Multiline String

Normally, we would use one of the following syntax to create a multiline string:

    
    var string1 = 'This is line 1\n\
        This is line 2';
        // or
    var string2 = 'This is line 1\n' +
        'This is line 2'
    

Now, with template strings, any new line character in source code is treated as an actual new line character. The code can be written as:

    
        var string1 = `This is line 1
            This is line 2`;
    

Variable Substitution

Using template strings, we can not substiute variables on the runtime. To use this feature, wrap the variable name inside ${} in the string template:

    
    var a = 10,
    string=`Value of a is ${a}`;
    console.log(string);// Value of a is 10

This can also be used for expressions:

    
    var a = 10,
        string = `a times 10 is ${a*10}`;
    console.log(string);
    // a times 10 is 100
    function sum (a, b) {
        return a + b;
    }
    
    
    var string2 = `10 + 20 = ${sum(10, 20)}`;
    console.log(string2);
    // 10 + 20 = 30
    

Tagged Templates

Tag is a function that has the ability to intercept and process templates. Tag is a function which gets the individual string fragments in a template as the first argument and variables as other arguments:

    
    function tagFn (strings, ...value) {
            console.log(strings[0]); // "10 + 20 = "
            console.log(values[0]); // 10
            console.log(values[1]); // 20
            return `something else`;
    }
    var a = 10,
        b = 20;
    tagFn` 10 * 20 = ${a+b}`
    // something else
    

This is a pretty powerful feature and can be used for purposes like sanitization of HTML, i18n or something similar.

Written by Mayank Patel

Written by inrhythmAdmin · Categorized: Software Engineering · Tagged: ES6, Node.js, software engineering, tutorial

Feb 09 2015

Top 3 Reasons for Software Developers to Make a Move

Is the grass really greener on the other side? It’s the age-old question for anyone looking to make a job change. For software developers and UX designers, it can be easier to identify that it’s time for a change by asking 3 simple questions:

  1. Am I bored regularly?
  2. Have I learned anything new in the past 6 months?
  3. Do I have a clear path for growth?

Beat Boredom with Cutting Edge Technologies

If only every project could be interesting and exciting! The reality is that not every project sparks innovation, but working with the right tools and frameworks can make a huge difference. If you’re currently not working with the latest frameworks and using modern technologies, it’s easy to get bored.

Skills Development is a Continuous Journey

From learning a simple coding short cut to understanding Agile, you should be continuously developing your skills to position yourself and your team for success. If you don’t have the bandwidth, proper mentorship or the chances to continuously learn, it’s time to find a new opportunity that allows you to further your skills development.

There’s Always Room to Grow

Building your portfolio, continuously developing your skills and taking on new projects are key components of personal growth, but they’re not necessarily going to get you a promotion. You should have clear objectives outlined for your career growth plan and avenues to reach them. If you feel like it’ll be a long time before you move up the ladder or if it feels like you’ve reached the ceiling, it’s likely time to move on.

If you’re on the fence about changing jobs, and you identified with one or more of the above, check out our open positions. We’re growing like crazy here, and looking for top UX Designers and Front-End Engineers to work on a range of projects from building web apps from scratch to unifying brand experiences across multiple lines of businesses.

Written by David Gaspin

Written by inrhythmAdmin · Categorized: Software Engineering, Talent

  • « Go to Previous Page
  • Go to page 1
  • Interim pages omitted …
  • Go to page 11
  • Go to page 12
  • Go to page 13

Footer

Interested in learning more?
Connect with Us
InRhythm

140 Broadway
Suite 2270
New York, NY 10005

1 800 683 7813
get@inrhythm.com

Copyright © 2021 · InRhythm on Genesis Framework · WordPress · Log in

This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Cookie settingsACCEPT
Privacy & Cookies Policy

Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Privacy Overview

This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.

Necessary Always Enabled

Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.

Non-necessary

Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.